-
Notifications
You must be signed in to change notification settings - Fork 84
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
profile-sync-daemon fails to work properly after battery dies on laptop #178
Comments
To the bug reporter - Please post the output of |
Same issue, also Debian (testing/unstable).
Removing the backup dir fixes the problem. (I removed the ovfs dir too.) |
Can you outline the steps for me to reproduce on my system? I can spin up a debian VM if needed. |
I'm not 100% sure what triggered it. My system went into hibernate because I forgot to plug my charger in, haha. So my whole system hibernated, then I brought it back and the browser seemed fine. Sometime later the browser itself crashed too. I think I restarted the browser and hibernate had done something dumb, so chrome claimed it had crashed when it oepend back up. I noticed my hard disk wasn't going into standby (the whole reason I use psd and asd -- my hdd sucks and gets hot when it's constantly spinning, so I want it to spin down the vast majority of the time). So I checked the Sorry I can't be of more help. |
Doesn't sound like a psd issue... I put sid on a VM and simulated power failures by closing the VM without shutting it down. I just got the expected recovery snapshots and a functional browser profile. I never used hibernate (not just testing the VM but ever though).. |
I'm the original bug reporter. psd p: Profile-sync-daemon v6.25 on Debian GNU/Linux stretch/sid Systemd service is currently active. Psd will manage the following per /home/rmm/.config/psd/.psd.conf: browser/psname: chromium/chromium browser/psname: firefox/firefox Then when I stop the psd service. Aug 8 13:16:07 RMMbook systemd[4300]: Stopped Timer for profile-sync-daemon - 1Hour. The psd service is stopped, but the mounts still exists, and the data where not synced back: overlaid on /dev/shm/rmm-chromium type overlay (rw,nosuid,nodev,relatime,lowerdir=/home/rmm/.config/chromium-backup,upperdir=/dev/shm/rmm-chromium-rw,workdir=/dev/shm/.rmm-chromium) The directory, "lowerdir=/home/rmm/.mozilla/firefox/a38n37oj.default-backup" exists while psd is running, but doesn't exist anymore after stopping psd, eventhough the mount still exist. Then I unmount those mounts by hand. in the *-rw directories are the changes made by the browsers, and also a file called "null" which are a symlink to /dev/null (that seems to be one way to get those "null" files, I'm not sure yet if there are others). The other directories are empty. |
I disabled the overlayfs. The result is following: After stopping the psd service: So I get the same messages, BUT the data is synced back. Also now there is a symlink "null" pointing to /dev/null in the /home/rmm/.mozilla/firefox/a38n37oj.default and the corresponding chromium directory. |
This is very unusual... do you have any type of non-standard setup? Psd is designed to prevent the browser itself from starting while the sync is in progress, so it creates that link to /dev/null (https://github.com/graysky2/profile-sync-daemon/blob/master/common/profile-sync-daemon.in#L432) Once the sync finishes, it unlinks the /dev/null and links it to the tmpfs target (https://github.com/graysky2/profile-sync-daemon/blob/master/common/profile-sync-daemon.in#L458) For some reason, your setup seems to be breaking down between there... I need to be able to reproduce it to figure out what's going on and thus far, I cannot. |
I've got a completely standard setup. Debian Testing. I deleted the I guess the main problem is the message Am 8.8.2016 20:05, schrieb graysky:
|
Again, just stopping the service gives you this error? I will again try to repeat in a VM running stretch. Please provide me with the output of |
yes, just stopping the service, gives the message. psd p: Profile-sync-daemon v6.25 on Debian GNU/Linux stretch/sid Systemd service is currently active. Psd will manage the following per /home/rmm/.config/psd/.psd.conf: browser/psname: chromium/chromium browser/psname: firefox/firefox |
that freaking idiot tries to format the comment signs in my psd.conf and it doesn't allow to upload it... USE_OVERLAYFS="yes" |
I still cannot reproduce in my stretch VM. Insidently (and not related), you're defining VOLATILE in the config file; this has been deprecated since v6.16. |
I am not sure what to do here since I am unable to reproduce this behavior in a sid VM. @yennor - does the current version still do this for you or have you stopped using it all together? |
I can try to help you reproduce this but we'll have to work together a bit. Every time this has happened to me it's been because my battery died while I had chrome (beta or unstable) open. My computer is set to try to hibernate when it dies, but it only sometimes works. Other times it just shuts down. I also use laptop-mode-tools, so it goes through this process when my battery is at 2 or 3 percent or something. I think the problem comes when my laptop starts trying to elegantly hibernate, but oh no, the power is just too low and cuts out, terminating my laptop's execution completely. In the middle of trying to elegantly hibernate, it runs the systemd job for profile-sync-daemon, which attempts to sync things in memory back to disc. At some point during this process, it performs actual copies of data from memory to disc. I think the issue above happens when my laptop happens to die in the middle of psd's systemd job. Enough of the data has been copied back but not all, such that psd doesn't think that the dirs are synced. So, it tries to create symbolic links to files that exist, causing bugs, causing the above problem I posted. The quick fix is to check for this kind of situation and delete the backup dir in the script if so. Then the rest works fine. Funny thing, I use asd too for some |
I never use hibernate but perhaps the problem is an incomplete write out to the disk? Seems like quite a few variables at play in what you're describing. |
sorry, I didn't reply earlier, I didn't had an Internet connection the last few weeks. I stopped using psd, because it was too much work fixing the profiles every 2-3 days. |
I am not an expert with systemd units but I am wondering if adding the following
|
@JanLuca - Any update? |
@graysky2: I have no futher informations, as described I could not reproduce the bug, too |
OK, reopen if needed. |
Forward bug report from Debian bug tracker: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833135
Package: profile-sync-daemon
Version: 6.25-1
After a system crash (or blackout), profile-sync-daemon doesn't work properly anymore, when using the overlay filesystem.
It does not sync any changes back anymore, maynly because of following message:
It says it is successfull, but in reality it didn't sync changes back, also the mounts still exist even after ending the daemon.
After deleting that null file, things seem to work again. I'm not sure what that "non-directory" message has to do with everything.
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages profile-sync-daemon depends on:
pn rsync
profile-sync-daemon recommends no packages.
Versions of packages profile-sync-daemon suggests:
ii libpam-systemd 230-7
ii systemd-sysv 230-7
-- no debconf information
The text was updated successfully, but these errors were encountered: