Created attachment 298535 [details] profile-sync-daemon-2.6.ebuild Symlinks and syncs browser profile dirs to RAM thus reducing HDD/SDD calls and speeding-up browsers.
Created attachment 298537 [details] cronjob
Created attachment 298539 [details] daemon
Created attachment 298541 [details, diff] psd-manreadme.patch
Created attachment 298543 [details, diff] psd-pid.patch
committed to sunrise-overlay! https://overlays.gentoo.org/svn/proj/sunrise/reviewed/www-misc/profile-sync-daemon/
versione bump 3.13 our they moved on git https://github.com/graysky2/profile-sync-daemon sunrise ebuild is not working anymore since the file is not available any more
+*profile-sync-daemon-3.13 (19 Sep 2012) + + 19 Sep 2012; Julian Ospald <hasufell@gentoo.org> + +profile-sync-daemon-3.13.ebuild, +metadata.xml: + initial import wrt #398431
(I didn't know if this comment should be in the form of a forum message, where I originally posted it, a comment added to this bug report, or a comment on a new bug report.) I'm currently running www-misc/profile-sync-daemon-5.36 on my system, without systemd. After emerging it, I chmod+x the hourly cron job, so it syncs at least once an hour. However after a couple of normal system reboots, I've been greeted with the "crash" message upon starting www-client/firefox-22.0. If I manually issue a /etc/init.d/psd resync before I reboot, the firefox crash message doesn't appear on reboot. So should the profile-sync-daemon init-script stop function call a sync before it unsyncs? I don't know if the normal profile-sync-daemon unsync process performs a sync before unsync, but on my system it doesn't appear to do so. Should this be fixed in the init-script? Thanks..
(In reply to Jason Lamb from comment #8) > (I didn't know if this comment should be in the form of a forum message, > where I originally posted it, a comment added to this bug report, or a > comment on a new bug report.) > > I'm currently running www-misc/profile-sync-daemon-5.36 on my system, > without systemd. After emerging it, I chmod+x the hourly cron job, so it > syncs at least once an hour. However after a couple of normal system > reboots, I've been greeted with the "crash" message upon starting > www-client/firefox-22.0. If I manually issue a /etc/init.d/psd resync before > I reboot, the firefox crash message doesn't appear on reboot. > > So should the profile-sync-daemon init-script stop function call a sync > before it unsyncs? I don't know if the normal profile-sync-daemon unsync > process performs a sync before unsync, but on my system it doesn't appear to > do so. Should this be fixed in the init-script? > > Thanks.. from profile-sync-daemon script: unsync) [[ -f $DAEMON_FILE ]] && do_sync && kill_browsers do_unsync ;; So calling "unsync" should do a sync when the DAEMON_FILE is present. The thing is... it should be present since the DAEMON_FILE is the PIDFILE in our case. Will have to investigate.
actually... the crash message might be just due to the way profile-sync-daemon kills the browser to ensure profile-integrity change your bookmarks, reboot and then check if the bookmarks still exists
(Thanks for the quick response Julian..) I can definitely confirm I am not getting a good sync before unsync on my system. I just now had several tabs open in Firefox. Closed them one by one until I was left with only one. Added gentoo.org to my bookmark bar by dragging it to the bar. Closed Firefox. Rebooted normally. Upong reboot when I opened Firefox I got the crash message asking if I wanted to restore my session, which was the original multi-tab session referenced above. And there was no bookmark for gentoo.org on my bookmark bar. I closed the restore session request, which just brings me one Firefox window of my homepage. I then opened up various Gentoo pages, added the same bookmark to bookmark bar. Closed Firefox. Rebooted system. Upon reboot, and running Firefox, it again asked me if I wanted to restore my original multi-tab session referenced in the first paragraph above. I'm definitely not getting a sync before unsync on my system. I also have the /run/psd.pid daemon file, as specified in the /etc/conf.d/psd configuration file. Jason
Do you get a sync with regular "/etc/init.d/psd stop"?
Yes. It is definitely performing a sync on stop. After rebooting and restarting Firefox, it's coming up in the last state I left it in prior to the reboot. I even started a bunch of tabs, added some bookmarks and then ran "/etc/init.d/psd stop", only to have it close Firefox on me. However, when I rebooted it greeted me with the "Restore Session" window again, only this time, it was the exact same session that I had, when I performed the "/etc/init.d/psd stop". Jason
it seems your /home dir gets unmounted before the psd daemon is stopped
do you run ZFS by any chance?
Created attachment 353734 [details] boot / shutdown message log No. I'm just using ext4, (ext2 on boot). Also I don't think that psd is shutting down after dismounting my home directory, but here's my boot/shutdown message log, just in case.
Created attachment 353736 [details] emerge --info Here's my emerge --info too. Could my using preload have anything to do with this issue? Thanks..
we figured out the problem, but we are unsure yet how to fix it for testing you can remove: umount -a -t tmpfs 2>/dev/null from /etc/init.d/swapfiles and use this service file for psd: https://gist.github.com/hasufell/66ef7d64297c8725eb09
Thanks again Julian, With those two changes, everything works as expected now. Jason
Lastly, emerging the package installs an /etc/psd.conf file, in addition to the /etc/conf.d/psd file. I'm not sure if the /etc/psd.conf is needed. I deleted it, and everything appears to be working correctly without it.
(In reply to Jason Lamb from comment #20) > Lastly, emerging the package installs an /etc/psd.conf file, in addition to > the /etc/conf.d/psd file. I'm not sure if the /etc/psd.conf is needed. I > deleted it, and everything appears to be working correctly without it. don't delete it, it will break everything when you update your init.d service file /etc/conf.d/psd is obsolete now, use /etc/psd.conf
Ok. I got it back by re-emerging the package. Will use that file, (and not /etc/conf.d.psd), as the configuration file. (thanks again..)
