That message is unrelated to psd. It is informing you that the mount target contains files. If you want to avoid it, just umount the target, inspect the contents, and if you don't care about them (i.e. just cache stuff), delete it, then remount it to tmpfs and problem solved.

orschiro wrote:

psd takes care of my ~/.cache to sync my Chromium profile. I set up the following tmpfs in /etc/fstab as suggested in the Wiki:

No, psd will not touch ~/.cache unless you modified it. It only manages known profile dirs for supported browsers.

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

Hi,

I installed psd on Ubuntu 13.10. Works fine, except on reboot I have to restart it manually. Before I do that I have a broken symlink in my .mozilla/firefix directory. After the restart everything works fine, until the next reboot.

mw@x220:~$ sudo service psd restart

* Restarting Profile-sync-daemon profile-sync-daemon /home/mw/.mozilla/firefox/firefoxDefault does not exist or is a broken symlink! Is /tmp unmounted?

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

@frank - I dunno where ubuntu [upstart] logs the output of daemons but I might look around for the log to see if it's actually getting shutdown properly on a reboot. Anything funky with your system setup (lvm or encrypted home or anything like that)? If the daemon is properly shutdown the symlinks should be removed. Try this, disable psd, manually stop it, manually start it, verify it is working, stop it, verify there are no symlinks.

mw@x220:~$ psd p
Profile-sync-daemon v5.43 on Ubuntu 13.10.
Daemon pid file is present.
Resync cronjob is present.
Psd will manage the following per /etc/psd.conf settings:
mw@x220:~$ sudo service psd stop
[sudo] password for mw:
/home/mw/.mozilla/firefox/firefoxDefault does not exist or is a broken symlink! Is /tmp unmounted?

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

frankfender wrote:

Yes, I do have an encrypted home (encfs)...

psd manpage wrote:

BUGS Discover a bug? Please open an issue on the project page linked below.

· It is known that on slow systems with large profiles, the sync'ing step sometimes take longer than the boot-up of the WM. Therefore, users can theoretically start their browser before the profile has been tran‐ sitioned to tmpfs. This is particularly prevalent on systems with slow HDDs running systemd. This effect can be exacerbated with excessively large profiles that store mail as well as browser profiles.

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

graysky wrote:

That message is unrelated to psd. It is informing you that the mount target contains files. If you want to avoid it, just umount the target, inspect the contents, and if you don't care about them (i.e. just cache stuff), delete it, then remount it to tmpfs and problem solved.

Thanks for that. For some reasons ~/.cache was full of no longer used files. I cleaned it up, reactivated it in /etc/fstab and now it remounts without a flaw.

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

Is it good to have the Firefox profile sync'd with Dropbox while using psd? I have two computers and want to sync 'em all. And needless to say, how will it work?I hope this will be added to psd's TODO list.

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

Dropbox will download the files from the web and place them in a folder in your computer. If you change your file "onlinely", dropbox will download the changed file(s) to your computer, and vice versa. It syncs your computer with the web. You have the physical files in your computer while you have the "copy" in the web.

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

Thank you very much for this! This script is fantastic for laptops with SSD drives for some very good reasons:1) Faster browser as you said due to RAM being significantly faster than disk; SSDs have faster seektime and dont have a disk to spool up, so they are less affected in this sense, but any read from disk costs time.2) SSD lifespan- as the web browser is one of the most used applications, it contributes many writes/wear to the SSD. This script essentially eliminates many repetitive writes, thus contributing to SSD drive lifespan.3) Battery life- less writes = less power consumption, and as this script essentially reduces the amount of repetitive writes, it also increases battery life (by how much depends I suppose).

I had been meaning to get around to cooking up a script to do this, but now I dont need to! Thanks

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

I installed psd and am trying to synchronize my Firefox profile, but I can't get it to synchronize back at shutdown. I also tried to synchronize the same directory with anything-sync-daemon (not advised, I know) but it also didn't synchronize at shutdown. Hence there's some more fundamental problem here with systemd shutdown scripts not being run at shutdown, but I'm not sure which log files to check for this.

Every time I reboot I get a Firefox_Profile-backup-crashrecovery folder created, and my profile clearly has not synchronized back to disk because it does not remember the tabs that I opened during that session, nor any bookmarks or changes to Firefox settings.

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

Yes, it does sync back successfully. Like I said, I believe that my systemd scripts that are supposed to run at shutdown are not being run for some reason and I don't know what logs I should be looking at.

/mnt/SSD_Docs is a ntfs partition, mounted at boot using ntfs-3g and with the following options:

Re: profile-sync-daemon - keep browser profiles in tmpfs and sync'ed

I wonder if systemd takes the mount down before psd syncs back... not too sure how to debug it though. I use both ext4 and btrfs for my /home and never have the problem you are describing.

EDIT: I am not a systemd service expert by any means, but the included service for psd does Wants=local-fs.target so I would think that systemd is aware of that and that would play into the order in which it shuts down things... what if you let systemd automount your /mnt/SSD_Docs like this in your /etc/fstab?