Regressions in v6.15 on Ubuntu: recursive symlink in firefox profile, overlay dir trouble.

[glitsj16]

After using psd v6.12 on Ubuntu without hickups, I started seeing a few odd symptoms after upgrading to v6.15 from the graysky/utils PPA. Using the same configuration & versions on Arch Linux produce no ill effects. Yet in Ubuntu 15.10 the below symptoms are showing:

(1) 'psd p' never reports anything for overlayfs size; (2) 'systemctl --user stop psd' never releases the psd-related dirs in $XDG_RUNTIME_DIR; (3) .. which causes a recursive symlink to appear inside the firefox profile dir pointing to the $XDG_RUNTIME_DIR.

Not 100% sure, but I'm suspecting this started showing after the fix was released for https://github.com/graysky2/profile-sync-daemon/issues/138.

I've tried with/without using the overlay, the above symptoms keep reproducing themselves and I'm back to v6.12 which works flawslessly on Ubuntu 15.10. If you need additional info besides the below, give a shout. Many thanks for all your efforts on psd, asd & other projects BTW.

= = =

$ cat ~/.config/psd/psd.conf
USE_OVERLAYFS="yes"
BROWSERS="firefox"
VOLATILE="/dev/shm"
USE_BACKUPS="no"

= = = v6.12 from PPA :: works flawlessly = = =
$ psd p
Profile-sync-daemon v6.12 on Ubuntu 15.10
 Systemd service is currently active.
 Systemd resync-timer is currently active.
 Overlayfs v23 is currently active.

Psd will manage the following per /home/glitsj16/.config/psd/psd.conf:
 browser/psname:  firefox/firefox
 owner/group id:  glitsj16/1001
 sync target:     /home/glitsj16/.mozilla/firefox/release.profile
 tmpfs dir:       /run/user/1001/glitsj16-firefox-release.profile
 profile size:    39M
 overlayfs size:  14M
 recovery dirs:   none

= = = v6.15 from PPA :: problematic = = =

$ psd p
Profile-sync-daemon v6.15 on Ubuntu 15.10
 Systemd service is currently active.
 Systemd resync-timer is currently active.
 Overlayfs v23 is currently active.

Psd will manage the following per /home/glitsj16/.config/psd/psd.conf:
 browser/psname:  firefox/firefox
 owner/group id:  glitsj16/1001
 sync target:     /home/glitsj16/.mozilla/firefox/release.profile
 tmpfs dir:       /run/user/1001/glitsj16-firefox-release.profile
 profile size:    39M
 overlayfs size:
 recovery dirs:   none

[graysky2]

I am confused by the output you posted for 6.15 above. Could there be any cut/paste error? Please make sure 6.15 is running and post the output of:

ls -la $HOME/.config/psd

Then post the output of:

psd p

EDIT: AH! I see what's wrong (but that doesn't explain the output you posted which could either suggest a new bug or a copy/paste error).

[graysky2]

Github closed this automatically when I referenced it in the commit. Reopened.

[glitsj16]

Thanks for looking into this. I've reinstalled v6.15 and tested, again showing the same symptoms. Output per your request: https://gist.github.com/glitsj16/659c4e5bef8ce7a69c02 I've added a few other things, to show what exactly happens after a cold start and after stopping psd once. Hope this helps to clear any confusion :)

Cheers

EDIT: just noticed your fix is in, will do another test and report back.

[graysky2]

Please try v6.16 which is in my PPA now.

[glitsj16]

Ahh, sweet sixteen .. Confirming that v6.16 fixes this issue. No more 'hanging' dirs in $XDG_USER_DIR, hence no recursive symlink any longer. After stopping psd I do have a release.profile-back-ovfs dir on disk, although I'm running psd with USE_BACKUPS="no". Unrelated, or is this by design? Just asking, as I will need to adjust my general backup scripts and exclude that one to avoid redundancy. Really appreciate all your efforts graysky, cheers!

[graysky2]

Yes, see the FAQ in the manpage. If using overlayfs it is by design. We cannot sync back to the lower dir which was causing some problems when it was set to do so. The work around is to create a backup, anyway from the manpage:

Q2: Why do I have another browser profile directory "foo-back-ovfs" when I enable overlayfs?

A2: The way overlayfs works is to mount a read-only base copy (so-called lower dir) of the profile, and manage the new data on top of that. In order to avoid resyncing to the read-only file system, a copy is used instead. So using overlayfs is a trade off: faster initial sync times and less memory usage vs. disk space in the home dir.

Thank you for discovering this bug :thumbsup:

[glitsj16]

Good to know, thanks for your kind and instructive explanation. I did go over the FAQ but I missed that one. Back to smooth browsing.. Glad I caught it, some recent rsync logs related to my backup routine showed the continuously expanding recursion of the symlink. Have a nice weekend.