On Tue, 3 May 2016 15:24:47 -1000 Joel Roth <[email protected]> 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 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
