-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stopping psd on shutdown could get timeout and killed #352
Comments
Have you tried experimenting with a |
Not yet because I have more issues with PSD (firefox localstorage completely broken with PSD on, etc), unfortunately :( |
I've got a related problem, but different log output. I've got psd managing two Firefox profiles, Chromium, and Brave. I only really use Brave, so sync'ing its data takes significantly longer. I usually experience data loss (i.e. Brave forgets open tabs and windows, etc) if I reboot the system without quitting Brave manually first, waiting a few seconds, then logging out of my desktop session. I just had to login remotely and reboot the machine after my desktop environment went into an infinite loop. Here are a few pertinent lines from my journalctl output:
I trimmed out a bunch of unrelated stuff (e.g. a few other services that hung around a bit too long got SIGKILL'd too), and added some blank lines around snippets of logs that belong together. Notice that:
What's the best way to fix this? I looked into The value for My reading of the Perhaps this is the culprit?
I strongly suspect that the solution (for me at least) will be to override Once I've worked out a clean way to "fix" this I might pop back with the relevant command... For anyone wondering, I'm on Pop!_OS 22.04. To all extents and purposes, I think that's equivalent to me being on Ubuntu in terms of how we can expect this area of the system to behave. |
I've worked around this on my Pop!_OS (i.e. Ubuntu-like) machines like this: sudo mkdir /etc/systemd/system/[email protected]
sudo tee -a /etc/systemd/system/[email protected]/timeout.conf <<EOF
[Service]
TimeoutStopSec=30s
EOF To get the new setting picked up run To check that it's been detected correctly, use systemctl show user@$(id -u) | grep TimeoutStop
TimeoutStopUSec=30s
TimeoutStopFailureMode=terminate You should see the new value from your config file is now assigned to From what I've learned this evening, I think you could argue that this is a bug in the operating system. I don't think the OS has any right to set the timeout before it sends I assume it's present in Ubuntu as well as Pop!_OS, but I don't know. But as such, I wonder if it's worth documenting this problem fairly prominently in the README? I've been putting up with intermittently (and unpredictably) losing all my browser state (with my open tabs reverting to whatever I was reading a couple of months ago) for at least two years now, before deciding to dig in and find out what was going wrong. I can imagine most people might just blame |
This leaves PSD in ungrateful state. Probably
TimeoutStopSec
should be set for psd.service with a higher value.The text was updated successfully, but these errors were encountered: