On Tue, 3 May 2016 15:24:47 -1000
Joel Roth <joelz@???> wrote:

> Hendrik Boom wrote:
> > There's a small number of directories that are supposed to be on
> > the root filesystem, or otherwise available during boot. I
> > believe /etc and /bin are two of these.
> >
> > /usr is not. I suspect /var isn't either.
> >
> > init is supposed to be able to read /etc/fstab to find the others.
> > That's why /etc has to be on the root filesystem.
> >
> > So it is available for init-time configuration files.
>
> /etc is the right place for config files, and init scripts
> have historically lived there. I hope we can agree on at
> least this part!

No doubt about it. /etc is the tree where init scripts, run scripts,
EpochConfig files belong.

I think the nonobvious thing comes from the daemontools-inspired inits,
which at a minimum have a /service directory somewhere that contains
symlinks to the actual service directories. No reason that can't be
somewhere under /etc. Daemontools, and maybe some other ones, also have
a /command directory, directly off the root, that houses executables
specific to themselves. It's possible this odd placement is to
guarantee they're available the minute the root partition is mounted.

Bizarrely, Runit on Void Linux has a directory at /run/runit that has
all sorts of oddball symlinks. I believe this is so, if /etc/ is
mounted read-only, parts of Runit that need to change file conttents
can still operate. I think this is usually placed at /var/run/runit,
but on Void it's just /run/runit.

I did a little runit experimentation during my Manjaro Experiments, and
have found that Void's runit implementation is much more complex and
full of chained symlinks than was my Manjaro alt-initted runit.

SteveT

Steve Litt
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21