Mailing List Archive

daemontools and /run, /var/run, /private/var/run
For the past few years, I have been seeing increasing usage of /run
and /var/run tmpfs filesystems. This filesystem is used to store
temporary things like the pid file unix domain socket, etc. I used to
wonder about the use of this scheme. For the past few months I have
been using the tiny SBCs, mostly running some version of Debian linux.
Most of these devices have the entire OS on a SD/MMC card. One of the
requirements is that you should be able to simply turn off the power
without executing the shutdown command, which will properly sync the
filesystem to a consistent state so as not to corrupt the SD card.
Also you don't want too many writes happening on the SD card. There
are few distributions that make it safe to turn off the power without
corrupting the filesystem and also minimize the IO. Mostly it is
achieved by having the /var filesystem in RAM (tmpfs). You can also
mount all filesystems other than /var readonly. As far as Mac OSX is
concerned, /usr, / file system are read only and is out of bounds for
any modifications with SIP in place.

daemontools makes this goal impossible, because it maintains state
information in a directory named "supervise" in the service directory.
So unless your service directory is in /var filesystem, You will have
an issue of writing to a filesystem that may be mounted read only.
daemontools needs to create the supervise directory in /run. systemctl
on linux does something similar. It has the original config in
/lib/systemd. The config is copied to /etc/systemd and subdirs. If you
change anything you have to do 'systemctl daemon-reload'. All other
data that gets modified gets stored in /run. I have modified svscan.c,
svc.c, svstat.c, svok.c to make this possible. Just shooting out this
mail for information purposes only. I would be keen to know
alternative approaches.

--
Regards Manvendra - http://www.indimail.org
GPG Pub Key
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC7CBC760014D250C
Re: daemontools and /run, /var/run, /private/var/run [ In reply to ]
> 8 okt. 2020 kl. 21:03 skrev Manvendra Bhangui <mbhangui@gmail.com>:
>
> As far as Mac OSX is concerned, /usr, / file system are read only and is out of bounds for any modifications with SIP in place.

That's not entirely true. In macOS 10.15 (Catalina) there is a mechanism for creating symlinks in / (see `man synthetic.conf`). So the /service, /package, and /command dirs that we've all learned to love can stay with us a while longer. :)

Also, it's not as simple as 'the root fs is read only'. For example, /etc is writable so the (not uncommon) practice of putting service dirs in /etc/sv is still viable.

Regards,
Malte
Re: daemontools and /run, /var/run, /private/var/run [ In reply to ]
Manvendra Bhangui <mbhangui@gmail.com> wrote:
> So unless your service directory is in /var filesystem, You will have
> an issue of writing to a filesystem that may be mounted read only.
...
> I would be keen to know alternative approaches.

Symlinks.
Re: daemontools and /run, /var/run, /private/var/run [ In reply to ]
On Fri, 9 Oct 2020 at 05:42, Malte Tancred <malte@tancred.com> wrote:
>
>
>
> > 8 okt. 2020 kl. 21:03 skrev Manvendra Bhangui <mbhangui@gmail.com>:
> >
> > As far as Mac OSX is concerned, /usr, / file system are read only and is out of bounds for any modifications with SIP in place.
>
> That's not entirely true. In macOS 10.15 (Catalina) there is a mechanism for creating symlinks in / (see `man synthetic.conf`). So the /service, /package, and /command dirs that we've all learned to love can stay with us a while longer. :)
>
> Also, it's not as simple as 'the root fs is read only'. For example, /etc is writable so the (not uncommon) practice of putting service dirs in /etc/sv is still viable.
>
synthetic.conf is a good way to have something in /. I discovered this
just 3 days back to have /service linked to /usr/local/etc/service.
But I think standardizing on /etc/sv now looks like a good idea that
will work for quite some times to come.