Will give it a go, do not clear cache as often as I should .... thanks
PC doesn't mess with the cache at all, just vacuums and reindexs the dbs. If you haven't run it before, I would be interested to see what kind of a savings it affords you. The output calculates all that.
[~]$ profile-cleaner f profile-cleaner v2.20 Cleaning profile for firefox Cleaning downloads.sqlite done -0 Mbytes Cleaning content-prefs.sqlite done -0 Mbytes Cleaning formhistory.sqlite done -.09 Mbytes Cleaning addons.sqlite done -0 Mbytes Cleaning places.sqlite done -8.31 Mbytes Cleaning phishing-blacklist.sqlite done -0 Mbytes Cleaning signons.sqlite done -0 Mbytes Cleaning search.sqlite done -0 Mbytes Cleaning stylish.sqlite done -0 Mbytes Cleaning cookies.sqlite done -1.25 Mbytes Cleaning chromeappsstore.sqlite done -0 Mbytes Cleaning index.sqlite done -0 Mbytes Cleaning urlclassifier3.sqlite done -16.09 Mbytes Cleaning search-history.sqlite done -0 Mbytes Cleaning phishing-blacklist-temp.sqlite done -0 Mbytes Cleaning extensions.sqlite done -0 Mbytes Cleaning webappsstore.sqlite done -1.68 Mbytes Cleaning permissions.sqlite done -0 Mbytes Cleaning cookies.sqlite.bak done -.71 Mbytes Profile(s) for firefox reduced by 28.15 Mbytes.
Last edited by Mr Green (2013-04-12 19:21:11)
can you clarify this phrase in the manpage:
Currently, psd does not work with encrypted home directories.
My /home is currently on a dedicate LUKS partition and root is on a clear partition.
Both on SSD.
Is it compatible/safe to use psd?
The default is to have psd start at boot. If you ask it to sync an encrypted partition that isn't decrypted, it will fail. I do not use encrypted partitions but users who do tell me that you need to be logged in for the system to decrypt.
Last edited by graysky (2013-05-17 14:38:29)
Yes, maybe it'll working if I modify psd service with systemd dependencies system.
With the `After=` directive.
This apart, if I understand well, there is no problem to use psd _after_ the partition decrypted.
No idea how you can have an after=user x logs in but go for it. Once the directory is viewable by your users, psd can sync it. Shutdowns will be funny too... You will need to sync back before you logout or else the sync will fail if the encrypted filesystem is not available to the user.
my experience with an EncFS home dir:
https://bbs.archlinux.org/viewtopic.php … 9#p1222719
sorry for crossposting
Thanks for your replies, precisions and warn about shutdown process.
Hopefully I can use it ^^
Thank you for pointing your post.
Your solution sound great but I think I'll look on systemd services side to have a more system wide solution.
You seem to ignore the psd-resync.service, is it intentional ?
How are you mounting /home?
If it is being done by systemd local-fs.target should already depend on it and you should need nothing more.
You can check with
systemctl show home.mount | grep WantedBy
The output is my uuid dev service
if I check psd.service dependencies
systemctl list-dependencies psd.service
│ │ ├─cryptsetup.target
│ │ │ └─firstname.lastname@example.org
│ │ ├─local-fs.target
│ │ │ ├─-.mount
Does it mean I've nothing to do, only enable psd and psd-resync services?
Does it sane for shutdown too?
My psd takes 40 seconds to load, and my profile is only 11 MB. What can I do to decrease this time?
@UC - Something is not right. Is this at boot up? Could it be that systemd is raping your HDD with all the parallel starts and psd just seems to take 40 sec?
Post the output of `systemd-analyze blame` and also of `psd p`
Same problem here
roger@slayerarch ~ % psd p Profile-sync-daemon v5.34 on Arch Linux. Daemon file /run/psd is present. Service is currently active. Psd will manage the following per /etc/psd.conf settings: browser/psname: chromium/chromium owner/group: roger/users sync target: /home/roger/.config/chromium tmpfs dir: /tmp/roger-chromium profile size: 31M browser/psname: opera/opera owner/group: roger/users sync target: /home/roger/.opera tmpfs dir: /tmp/roger-opera profile size: 94M
roger@slayerarch ~ % ana Startup finished in 193ms (kernel) + 1.621s (initrd) + 42.022s (userspace) = 43.838s 36.627s psd.service 11.344s teamviewerd.service 6.891s upower.service 1.726s home.mount 1.150s systemd-tmpfiles-clean.service 1.037s systemd-remount-fs.service 838ms colord.service 834ms dev-mqueue.mount 829ms dev-hugepages.mount 829ms sys-kernel-debug.mount 718ms systemd-vconsole-setup.service 712ms systemd-binfmt.service 594ms avahi-daemon.service 582ms systemd-logind.service 565ms systemd-udevd.service 522ms polkit.service 476ms systemd-udev-trigger.service 420ms zramswap.service 405ms sys-kernel-config.mount 358ms proc-sys-fs-binfmt_misc.mount 252ms systemd-fsck@dev-disk-by\x2duuid-361b5b2c\x2dfff5\x2d45ef\x2da0b1\x2d7a47dcacc450.service 241ms rtkit-daemon.service 212ms systemd-fsck@dev-disk-by\x2duuid-9940d092\x2ddc0a\x2d4af6\x2dac2f\x2d2f4bd9dfe2b6.service 199ms var.mount 183ms network.service 174ms alsa-restore.service 125ms dev-disk-by\x2duuid-dd3506fb\x2df05e\x2d4c57\x2db817\x2de6c1446eb631.swap 117ms psd-resync.service 109ms systemd-tmpfiles-setup.service 101ms udisks2.service 75ms systemd-sysctl.service 73ms systemd-readahead-replay.service 69ms systemd-random-seed-load.service 67ms systemd-readahead-collect.service 32ms systemd-user-sessions.service 11ms tmp.mount 7ms systemd-tmpfiles-setup-dev.service 1ms systemd-journal-flush.service 736us systemd-readahead-done.service
Well, for now, my firefox has gone away, something related a Glib but i really do not care about it.
Last edited by rutgerr (2013-05-19 19:56:32)
Here is systemd-analyze blame:
31.825s psd.service 4.375s NetworkManager.service 1.821s systemd-logind.service 1.501s systemd-vconsole-setup.service 1.241s accounts-daemon.service 1.191s polkit.service 966ms systemd-tmpfiles-setup-dev.service 884ms systemd-udev-trigger.service 857ms sys-kernel-debug.mount 857ms dev-hugepages.mount 856ms dev-mqueue.mount 833ms systemd-remount-fs.service 790ms sys-kernel-config.mount 766ms tmp.mount 738ms colord.service 723ms ntpd.service 517ms systemd-fsck@dev-disk-by\x2duuid-a791c311\x2d16f8\x2d4a41\x2daa99\x2d16129b0ae252.service 472ms systemd-fsck@dev-disk-by\x2duuid-547c1ce0\x2d2f83\x2d43af\x2db882\x2d32bdfd972122.service 468ms systemd-tmpfiles-clean.service 275ms systemd-user-sessions.service 274ms systemd-sysctl.service 263ms upower.service 172ms udisks2.service 151ms systemd-udevd.service 130ms boot.mount 118ms home.mount 98ms systemd-random-seed-load.service 90ms systemd-journal-flush.service 35ms rtkit-daemon.service 30ms systemd-tmpfiles-setup.service 5ms alsa-restore.service 3ms gdm.service 1ms systemd-localed.service 1ms sys-fs-fuse-connections.mount
and here is psd p:
Profile-sync-daemon v5.33 on Arch Linux. Daemon file /run/psd is present. Service is currently active. Psd will manage the following per /etc/psd.conf settings: browser/psname: google-chrome/chrome owner/group: username/users sync target: /home/username/.config/google-chrome tmpfs dir: /tmp/username-google-chrome profile size: 327M
Yikes! My profile is not 11MB, it's 327! I will clean that up and let you know how it goes. Also, it looks like psd takes 30 seconds, not 40, to start up.
Yeah, wish chromium/chrome had a more intelligent way to purge history... i.e. keep only 4 weeks worth rather than clear the last 4 weeks worth. Seems bass ackwards to me.
Very true, it seems there are a lot of threads on Google Forums requesting this. Here's a nice extension I just found that does this: https://chrome.google.com/webstore/deta … jbhiejjkph.
systemd-analyze blame 2.991s psd.service 648ms psd-resync.service
Running psd with Firefox
systemd-analyze blame 2.991s psd.service 648ms psd-resync.service
Running psd with Firefox
Against my 36 sec. It's a joke?
Wath could be wrong?
No joke, will say I run a SSD drive and have plenty of ram
maybe it would be good to provide an additional dependency as drop-in config for people with a seperate home partition.
sth. like this
„Je verdinglichter die Welt, je dichter das Netz, das der Natur überworfen wurde, desto mehr beansprucht ideologisch das Denken, das jenes Netz spinnt, seinerseits Natur, Urerfahrung zu sein." Theodor W. Adorno [aus: Wozu noch Philosopie]
I'm not an systemd expert, but would your home.mount depend on local-fs.target? Currently, psd.service looks like this:
[Unit] Description=Profile-sync-daemon Wants=local-fs.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/profile-sync-daemon sync ExecStop=/usr/bin/profile-sync-daemon unsync [Install] WantedBy=multi-user.target
Last edited by graysky (2013-05-26 22:02:46)
Is it me or firefox has changed its cache location? It's now in ~/.cache/mozilla instead of ~/.mozilla. The result is that firefox's cache is no longer relocated to /tmp.
seems like it's root fsck and remount and tmp tmpfs mount
ls /usr/lib/systemd/system/local-fs.target.wants/ systemd-fsck-root.service systemd-remount-fs.service tmp.mount
@krest - Haven't used firefox is a long time... does this help? https://wiki.archlinux.org/index.php/Firefox_Ramdisk
@kriz - Thanks for the suggestion. See v5.35.
Last edited by graysky (2013-05-29 04:35:41)