search

graysky2 / profile-sync-daemon

Symlinks and syncs browser profile dirs to RAM thus reducing HDD/SDD calls and speeding-up browsers.
https://wiki.archlinux.org/index.php/Profile-sync-daemon
Other
902 stars 84 forks source link

sync before suspend #231

Closed mattia-b89 closed 4 years ago

mattia-b89 commented 6 years ago

Several times I lost last part of my work on browser (open tabs, bookmarks, history, ...). This happens when my laptop fails to resume (a known hardware fault).

Talking about psd, is there a way to workaround it? Forcing the psd service to sync profile when pc calls for a suspend? Or actually is this already done?

graysky2 commented 4 years ago

I believe there is a way using the suspend.target ... let me look into it.

graysky2 commented 4 years ago

@mattia-b89 - I am not expert with this, can you please try using the following as your /usr/lib/systemd/user/psd-resync.service and report back.

  1. systemctl --user stop psd
  2. edit the file replacing it the the following contents
  3. systemctl --user daemon-reload
  4. systemctl --user start psd
[Unit]
Description=Timed resync
After=psd.service
Before=sleep.target
Wants=psd-resync.timer
PartOf=psd.service

[Service]
Type=oneshot
ExecStart=/usr/bin/profile-sync-daemon resync

[Install]
WantedBy=default.target suspend.target
mattia-b89 commented 4 years ago

sure, I've already done it! Now, I am trying to test the change but this is the hard part, now... In fact currently I do not have no more problems with suspend/resume and I am working on a laptop without the ability to extract the battery, thus I do not have idea on how to simulate a broken suspend/resume;
Any ideas?

graysky2 commented 4 years ago

First step is to confirm that the changes above give the expected behavior, eg that psd does the re-sync when you suspend the laptop. You should see this reflected in the journal.

This will show progress towards the hourly resync: systemctl --user list-timers So long as the timer triggered it, this will show you everything psd-resync did: journalctl --user -u psd

Please suspend the laptop taking note of the time you did it. Did you see a corresponding entry in the journal?

mattia-b89 commented 4 years ago

Unfortunately the change does not work as intended: I get no resync when I suspend the laptop.

I tried suspend laptop at 22:35 but as you can see from the output below, resync happened only at time 22:48, when I powered off the machine.

$ journalctl --user -u psd
...
...
...
-- Reboot --
Apr 14 22:32:43 arch-xps systemd[1226]: Starting Profile-sync-daemon...
Apr 14 22:32:43 arch-xps systemd[1226]: Finished Profile-sync-daemon.
Apr 14 22:48:30 arch-xps systemd[1226]: Stopping Profile-sync-daemon...
Apr 14 22:48:31 arch-xps profile-sync-daemon[4041]: firefox resync successful
Apr 14 22:48:32 arch-xps profile-sync-daemon[4041]: firefox unsync successful
Apr 14 22:48:32 arch-xps systemd[1226]: psd.service: Succeeded.
Apr 14 22:48:32 arch-xps systemd[1226]: Stopped Profile-sync-daemon.
-- Reboot --
graysky2 commented 4 years ago

I will have to read a bit more on this.

mattia-b89 commented 4 years ago

I am here to help you/test. Let me know

On Wed, 15 Apr 2020, 01:10 graysky, notifications@github.com wrote:

I will have to read a bit more on this.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/graysky2/profile-sync-daemon/issues/231#issuecomment-613725006, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFFN427Z4BNRUZ4D7E7ADRMTUNDANCNFSM4FQ2CJUQ .

graysky2 commented 4 years ago

@mattia-b89 - Try:

  1. systemctl --user stop psd
  2. Edit /usr/lib/systemd/user/psd-resync.service replacing it the the contents below
  3. systemctl --user daemon-reload
  4. systemctl --user start psd
[Unit]
Description=Timed resync
After=psd.service
Before=sleep.target
Wants=psd-resync.timer
PartOf=psd.service

[Service]
Type=oneshot
ExecStart=/usr/bin/profile-sync-daemon resync

[Install]
WantedBy=default.target
WantedBy=sleep.target
mattia-b89 commented 4 years ago

nope, same output as above

graysky2 commented 4 years ago

@mattia-b89 - Please see this discussion. Enabling this is surprisingly complex.

I find that messy since I aim to keep psd in systemd's user mode. But if you want to try with a sleep hook, you can try this: /etc/systemd/system/psd-resync-on-suspend@.service

[Unit]
Description=Profile-sync-daemon sync before suspend
Before=sleep.target

[Service]
User=%I
Type=oneshot
ExecStart=/usr/bin/profile-sync-daemon resync

[Install]
WantedBy=sleep.target

Note that if you have psd completely disabled in user mode, I believe this will still run when you suspend the device so that is NOT the intended behavior. I could code into psd itself a new token that we could use in this case (ie not resync but something like suspend-sync) which would have a check to see if it is actually running and do nothing if not, but that is just messy as stated above.

https://github.com/systemd/systemd/issues/15477

mattia-b89 commented 4 years ago

First, thank you for your effort! Right now, I think you have (already) done the most important thing: open a systemd issue upstream and honestly, it is hard to believe it lacks of a such feature.

Second, my personal thought is:
I am the first who think code must be as simple as possible. Keep it as elegant as today. No workaround, no complex code. Do not waste time for a trick that will never works 100% So, let's go beyond this feature but let's keep this issue open, as a place holder.

graysky2 commented 4 years ago

It seems there isn't support for this upstream: https://github.com/systemd/systemd/issues/15477 so we would need to set/unset a suspend inhibitor and get psd to listen to dbus for this to get into practice.

glitsj16 commented 4 years ago

I took a stab at implementing this as cleanly as possible in #261. Please feel free to review and make suggestions. I did some extended testing on both Arch Linux and Ubuntu LTS (16.04 and 20.04) with these patches and for me it works. If anyone wants to test, I put a few logger messages into the code, so grepping for those in journalctl should help assessing things work as expected. Looking at the /var/run/systemd/inhibit directory can confirm that the appropriate inhibit lock is indeed taken, released and re-taken as needed.

I do realize @graysky2 stated not wanting to integrate something messy, which I fully understand. So it's up to the owner to proceed on this as he sees fit.

graysky2 commented 4 years ago

@glitsj16 - This is looks like a really nice solution. If merged, I might add a setting with psd.conf to enable it so others who do not suspend can maintain a minimal footprint (although your helper script is tiny).

@mattia-b89 - Can you kick the tires on this on your system? I never suspend my workstation.

glitsj16 commented 4 years ago

[...] I might add a setting with psd.conf to enable it so others who do not suspend can maintain a minimal footprint [...]

@graysky2 Didn't think of that. Easily turned into an optional feature though. In fact, a default of "no" makes more sense. Not only will it take the user's explicit consent, it might make them aware of the added - now optional - dependency on gdbus/glib2. Will adjust the PR accordingly.

glitsj16 commented 4 years ago

Here's a short overview of the needed steps to have psd resyncing on suspend:

Invoke suspend (preferrably several times during the same desktop session):

Confirm it's working by grep'ing/tailing your journal:

$ journalctl | grep "psd-suspend-sync"
$ journalctl --no-hostname -f
graysky2 commented 4 years ago

@glitsj16 - Note that you can also see the inhibition lock via: systemd-inhibit --list

I merged, edited a little and rebased into my sync-on-sleep branch and tagged it as v6.39b2

Why does /usr/bin/psd-suspend-sync appear twice in a ps output?

% ps aux | grep psd-sus
facade  3694933  0.0  0.0  17068  6528 ?        S    06:09   0:00 systemd-inhibit --mode=delay --what=sleep --who=profile-sync-daemon --why=psd resync on suspend /usr/bin/psd-suspend-sync
facade  3694942  0.0  0.0   7140  2960 ?        S    06:09   0:00 /bin/bash /usr/bin/psd-suspend-sync
facade  3694945  0.0  0.0   7140   420 ?        S    06:09   0:00 /bin/bash /usr/bin/psd-suspend-sync

@mattia-b89 - Would you please build and use v6.39b2 and let us know?

mattia-b89 commented 4 years ago

@graysky2 sure, during the weekend I will give it a try

mattia-b89 commented 4 years ago

errata, I have just installed version 6.39b2

$ journalctl | grep "psd-suspend-sync"
Apr 29 18:43:53 arch-xps mattia[11041]: [psd-suspend-sync] Issueing suspend-sync request...
Apr 29 18:44:00 arch-xps mattia[11387]: [psd-suspend-sync] re-taking inhibit lock...

also $ ps aux | grep psd-sus returns 2 entries what else can I check?

glitsj16 commented 4 years ago

Why does /usr/bin/psd-suspend-sync appear twice in a ps output? also $ ps aux | grep psd-sus returns 2 entries

@graysky2 @mattia-b89 My guess is that this is a side-effect of grep'ing ps output, it includes the psd-sus from the piped grep. IMO it's more accurate to use pgrep. For example, even when psd is stopped, which also kills psd-suspend-sync, grep'ing ps output will still show what is being grep'ed for:

$ systemctl --user stop psd
$ ps aux | grep -c psd-sus
1
$ pgrep -cf "/usr/bin/psd-suspend-sync"
0

That being said, there are in fact always 2 psd-suspend-sync processes running if the user enabled the option. This is caused by the fact I used a direct call to systemd-inhibit in the take_inhibit_lock() function in profile-sync-daemon. Give me some time to experiment if using the logind D-Dbus API instead can bring it down to only the one psd-suspend-sync process running. I can see how that might cause confusion.

Just to be clear, functionality-wise there isn't (much of) a difference, psd is doing the resync on suspend just fine, as confirmed by 'systemd-inhibit --list' and/or 'journalctl | grep "psd-suspend-sync"'. While we're on the topic, I have a question/suggestion. Currently the below output is shown:

$ systemd-inhibit --list
WHO                             UID    USER      PID     COMM                 WHAT  WHY                                  MODE
[...]
profile-sync-daemon  1001  glitsj16  3556  systemd-inhibit  sleep   psd resync on suspend  delay

If you'd prefer to see the actual user under WHO (instead of profile-sync-daemon), you'll need to change --who="profile-sync-daemon" to --who="$user" in profile-sync-daemon's take_inhibit_lock() function. Any thoughts/preferences on this?

Thanks for pointing this all out here!

glitsj16 commented 4 years ago

@graysky2 shellcheck reported one issue with the profile-sync-daemon from your sync-on-sleep branch:

$ /usr/bin/shellcheck -s bash /usr/bin/profile-sync-daemon

In /usr/bin/profile-sync-daemon line 119:
    IFS=' ' read -r -a BROWSERS <<< "$BROWSERS"
                                                               ^-------^ SC2128: Expanding an array without an index only gives the first element.

For more information:
  https://www.shellcheck.net/wiki/SC2128 -- Expanding an array without an ind...

If you want I can open a seperate issue for it, but I guess you can fix it easily by using ... <<< "${BROWSERS[$@]}" correct?

graysky2 commented 4 years ago

If you want I can open a seperate issue for it, but I guess you can fix it easily by using ... <<< "${BROWSERS[$@]}" correct?

I will change it... (actually I did commit this before). Thanks!

Regarding the --who=... let's just leave it as-is since UID and USER are already captured. Let me know what you want to do about logind D-Dbus API but I think it's fine so long as seeing 2 is to be expected.

glitsj16 commented 4 years ago

Regarding the --who=... let's just leave it as-is since UID and USER are already captured.

True, that should do it.

Let me know what you want to do about logind D-Dbus API but I think it's fine so long as seeing 2 is to be expected.

I did another round of experimenting on this yesterday and - as we type - I'm trying to get basic confirmation on irc.freenode.org/systemd that this is indeed 'normal' behavior (if there is such a thing in D-Bus land). Using the logind API works, and that too shows the double script effect. Probably file descriptors, one for reading, one for writing.

After several days of quite extensive testing I do feel we have a reliable resync-on-suspend framework now. As long as users are informed not to kill one of both psd-suspend-sync processes, there's not much left to do on this. I'll keep you informed here if something relevant pops up from the IRC channel visit, shouldn't take all that long. Take care!

graysky2 commented 4 years ago

Sounds good @glitsj16. Thank you for the contributions and for the diligence!

@graysky2 sure, during the weekend I will give it a try

@mattia-b89 - Great, please do.

graysky2 commented 4 years ago

sure, during the weekend I will give it a try

@mattia-b89 - Any feedback?

mattia-b89 commented 4 years ago

I have been testing it for a week and I encountered no issue

On Tue, 5 May 2020, 15:27 graysky, notifications@github.com wrote:

sure, during the weekend I will give it a try

@mattia-b89 https://github.com/mattia-b89 - Any feedback?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/graysky2/profile-sync-daemon/issues/231#issuecomment-624054747, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEFFN4GJDXKAUQIAAMFS33RQAH55ANCNFSM4FQ2CJUQ .

graysky2 commented 4 years ago

I have been testing it for a week and I encountered no issue Glad to hear it, I too have been using it and seeing it work as expected.

glitsj16 commented 4 years ago

Great to hear the testing has gone OK. All the best in these bizarrely trying pandemic times.

graysky2 commented 4 years ago

You too!