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
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