First sync when laptop wakes from sleep always fails then delay before successful sync

[DoneWorkin]

Everything is working as it should - this is an optimization or improvement question (or perhaps feature request):

When my laptop wakes from sleep I immediately get a synchronization which fails out due to my WiFi card not being awake yet (so a network failure). I assume this sync takes place immediately because by clock time the last sync was a long time ago and the sync frequency has timed out.
The next sync takes several minutes (probably standard sync time).
During this delay time for the second sync I am in an error state on OneDriveGUI and if there are any remote changes there has not been a valid attempt to retrieve them (only the first failed attempt which will always fail on wake of the laptop).

Question: Is there a way to make the first sync on my laptop waking from sleep be delayed?
It would be nice if I could delay the first sync by something like 10 seconds so my WiFi card could wake up and be useful. I would need to do some testing to figure out that optimal delay number and I guess it might be different for different laptops.

Discussion: I understand that OneDrive probably has no idea the laptop was sleeping, so my thought was to apply this delay whenever the standard sync time has not only elapsed, but elapsed by a lot (indicating the laptop was sleeping). This delay would then have no impact to normal operations and only take place when the laptop is not processing for a long time (like when it is sleeping or hibernating).

My Setup: OneDrive is started by OneDriveGUI (I think?) - everything loads and starts at boot of my laptop. After first boot both OneDrive and OneDriveGUI remain running forever and I just sleep my computer when it is not in use and it wakes from sleep and everything resumes as you would expect.

OneDrive onedrive v2.5.9-1+np1+1.1
OneDriveGUI v1.3.0
Linux Mint 22.2

[abraunegg]

@DoneWorkin

When the client runs, when coming out of a sleep state is something more of a customisation of your operating environment than a feature request and/or code fix here.

The easiest element to implement is a systemd system-sleep hook.

A systemd-suspend.service runs executables in /usr/lib/systemd/system-sleep/ supporting 2 arguments for suspend, hibernate etc.

What you will need to develop is a script, that restarts the systemd service that is enabled, so when you are sleeping your laptop or waking your laptop - when you wake/resume, you restart the applicable 'onedrive' service(s).

This way on system resume, the service is restarted, clearing any stale curl status, but puts the client into probing the network in the correct manner waiting for this to be available and connected.

The systemd-suspend.service runs executables in /usr/lib/systemd/system-sleep/

You need to create the folder /usr/lib/systemd/system-sleep/ if this does not exist.

You then need to create a script, make it executable, and put it in that location. For example:

#!/bin/sh
# $1 = pre|post, $2 = suspend|hibernate|hybrid-sleep|suspend-then-hibernate

case "$1" in
  post)
    # If onedrive is a *system* service
    #
    # or change this to the actual service that has been created - and this is 100% unique based on the systemd services that OneDriveGUI creates
    /usr/bin/systemctl restart onedrive.service  
    ;;
esac

Use this as a starting point - augment as needed.

[DoneWorkin]

Thanks for the detailed response!
This will take a while to digest and fully understand - but thanks for taking the time to put me on the right track.

[DoneWorkin]

ok - I have a much better understanding now of how this is working and I don't think the systemd system-sleep hook is going to work in this case when using OneDriveGUI.

For anyone who looks at this in the future in respect to the question and answer - here is what I found out and why I don't think this answer will work when using OneDriveGUI.

I looked at the OneDriveGUI code and it looks like OneDriveGUI runs OneDrive directly as a subprocess so it can easily capture stderr and stdout for monitoring. So OneDriveGUI is not attaching to a running service, it starts a new OneDrive process itself.
Because it is not attaching to a running service we don't want to use a sleep hook to work with a service (and we can't stop and restart that process because then OneDriveGUI won't be connected to the new process properly).

I also checked for a running service while OneDriveGUI was running (with OneDrive running as a process) with systemctl list-units --type=service --al and confirmed that OneDrive was not running as a service.

The way OneDriveGUI creates a OneDrive process would lead me to believe a restart of the process would have to come from OneDriveGUI. OneDriveGUI would have to detect the condition, terminate the old process, and start a new one. I'm not sure that won't come with it's own unintended consequences (especially to change a rather minor thing).

As I stated up front in the question - everything is working fine so I am ok closing this question and accepting the short delay before the first successful sync when waking the laptop.
I am now much smarter about what systemd is doing and those sleep hooks seem useful for something - I am sure I will make use of this information in the future!

[abraunegg]

No problem

So essentially ... IMHO .. the solution to your scenario is to have OneDriveGUI be more mindful of the network connection state as to when it starts a process post system resume.

[DoneWorkin]

By my reading of the OneDriveGUI code and looking at logs I don't think that is quite what is going on. I don't think the process is ever stopped during any of the sleep/wake cycle and the OneDrive process is handling that just fine.

My take on what is happening during the sequence is:

1. When I start OneDriveGUI it is creating the OneDrive process and monitoring the output to generate all it's display stuff.
2. When the laptop sleeps there is no recognition of this state in OneDriveGUI and so the OneDrive process is also not stopped (I don't know if it internally is aware of being asleep - I have not really looked into the code of OneDrive yet).
3. Once the laptop wakes up I suspect the OneDrive process immediately realizes a bunch of clock time has passed since the last sync and it wakes up and tries to connect to the network and it fails (as the WiFi card is not connected yet).
4. OneDriveGUI properly sees this network failure and updates it's GUI accordingly.
5. The OneDrive process properly handles the situation and goes to sleep for some amount of time after the network failure.
6. The OneDrive process wakes up again and successfully syncs
7. OneDriveGUI sees the output of the OneDrive process and properly updates the icons and GUI (***** see below)

I think this also properly handles the network just going away while the laptop is running - so everything is really working the way it should.

I was just hoping to shorten the time between step 5 and step 6 above by detecting the sleep state and shortening the network retry.

As you noted above - one solution would be to have OneDrive GUI be mindful of sleep state and when waking from sleep and receiving that initial network failure it could stop and restart the OneDrive process. I agree that this would be a solution - but I fear it may just create other issues for not much benefit (and may be hard to convince the OneDriveGUI developer to implement🙂).

NOTE: I am running modified OneDriveGUI code to make the sequence above work properly and the network error clear itself. Current released code will leave the warning icons from the network error permanently displaying (until a user stops and starts the OneDrive process again on the OneDriveGUI main window).
If you or someone else tries this sequence with the current released version of OneDriveGUI (1.3.0) the above sequence isn't going to work the same way as the GUI and icons do not update quite properly as far as my thinking. I have submitted issues over on the OneDriveGUI github page and noted my suggested code changes in those cases.

[abraunegg]

I was just hoping to shorten the time between step 5 and step 6 above by detecting the sleep state and shortening the network retry.

The minimum time between automatic sync's is 300 seconds. A lower value causes issues (and is prohibited) - by the sound of it, it is this period you are talking about that is between 5 and 6.

The challenge here is - post waking from sleep, the internal curl engines (instances of libcurl) have internal timers. These internal timers then expire, which is why, post resuming from sleep, the client is is erroring out - as those curl instances were not closed on sleep init.

The further challenge is the whole WebSocket engine as well - similar here for receiving callbacks from the Graph API platform post sleep resumption - it is going to have issues until that is torn down and reinitialised once an error is detected. Again that would potentially surface as an error in application output and surface into the GUI.

A potential workaround for you, might be for you to use the systemd sleep element to 'exit' the OneDriveGUI so that the processes are correctly shutdown (thus exited), and then potentially restarted on resumption ...