Earlier today, I read a Phoronix article about changes coming in Firefox 147, the profiles folder will change from $HOME/.mozilla to .config and/or .local/share, following the XDG specs.
After discovering that, my concern went to the fact I'm using profile-sync-daemon (psd) - an utility to load the entire profile into RAM to save many writes on disk. Despite psd version 6+ having a systemd dependency, an older version compatible (5.75) with OpenRC is still available on gentoo repo.
The trouble is, upstream will certainly not patch an older version, as psd is now systemd only, gentoo's maintainer won't provide a patch, as he kinda has vanished, and currently, version 5.75 is condemned to be removed from repo at some point, see https://bugs.gentoo.org/678658
So I'm wondering, is there anyone out here, with time and skills, to create a fork of psd that would support OpenRC, or even better both systemd and openrc, and provide patches so that daemon continue working with future versions of Firefox ?
(the same question has been posted on gentoo's subreddit)
OpenRC, profile-sync-daemon, and newer Firefox
Message
I realize that this thread is now 4 months old, but I want to add my 2ct to this in case anyone's still affected by this.
One thing is simply that modern psd doesn't really *hard-depend* on systemd. Previously, it had a USERS="" key in the configuration, indicating what users to "su" as and symlink the configuration of. This was replaced by a systemd user service, instead, to relieve the logic from the script. This logic can still be supplemented with a simple init script and a cron job, and this is exactly what I did when I was running Slackware some 7 years ago: Init script, Cron job (care must be taken that the "su" invocations set a valid XDG_RUNTIME_DIR, my solution back then doesn't reflect modern elogind expectations). Alternatively, one can also make a simple shell script launched on login that just does "psd resync" inbetween 1h sleeps. These days, the best solution is probably to write an openrc user service, to just launch that resync script as I'm not aware of any user equivalent of the cron.hourly directory.
The other thing is that I'm not sure psd makes much sense anymore, or that it ever even did. Besides your browser, there's often other applications writing to disk constantly, and I believe a combination of a recent linux kernel plus an SSD that's not old enough to drive is enough to ensure a long SSD life. I'd advise to just tweak your fstab's commit= parameter to taste and leave the disk write cache to the kernel, honestly.
It also doesn't help that the only useful mode for this program (overlayfs mode) requires giving the user access to the "mount" command as root through the psd-overlay-helper command and attempts to sanitize its inputs didn't work out too well. I don't think this is something that will be solved without significantly restructuring the program, which I don't think there's a lot of interest to do.
One thing is simply that modern psd doesn't really *hard-depend* on systemd. Previously, it had a USERS="" key in the configuration, indicating what users to "su" as and symlink the configuration of. This was replaced by a systemd user service, instead, to relieve the logic from the script. This logic can still be supplemented with a simple init script and a cron job, and this is exactly what I did when I was running Slackware some 7 years ago: Init script, Cron job (care must be taken that the "su" invocations set a valid XDG_RUNTIME_DIR, my solution back then doesn't reflect modern elogind expectations). Alternatively, one can also make a simple shell script launched on login that just does "psd resync" inbetween 1h sleeps. These days, the best solution is probably to write an openrc user service, to just launch that resync script as I'm not aware of any user equivalent of the cron.hourly directory.
The other thing is that I'm not sure psd makes much sense anymore, or that it ever even did. Besides your browser, there's often other applications writing to disk constantly, and I believe a combination of a recent linux kernel plus an SSD that's not old enough to drive is enough to ensure a long SSD life. I'd advise to just tweak your fstab's commit= parameter to taste and leave the disk write cache to the kernel, honestly.
It also doesn't help that the only useful mode for this program (overlayfs mode) requires giving the user access to the "mount" command as root through the psd-overlay-helper command and attempts to sanitize its inputs didn't work out too well. I don't think this is something that will be solved without significantly restructuring the program, which I don't think there's a lot of interest to do.