[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

init system policy



Hi *,

I've drafted up a document that I think matches reality on how init systems work in Debian. It's at:

  https://github.com/ajtowns/debian-init-policy

and in (hopefully) easy-to-read pdf format at:

  https://github.com/ajtowns/debian-init-policy/releases/download/2014-11-16-1/init-policy.pdf

It's in three sections -- what admins should know, what daemon maintainers should know, and what init-system maintainers should know. (The last section isn't actually written up) I think it probably makes sense for section 1 to end up as user docs, while section 2 and 3 should go into policy, but for the time being I wanted to get it all in one place to make it a bit easier to review, and make sure the advice to everyone is actually consistent.

I've incorporated everything I think is relevant from current policy (in theory the git history shows what I dropped; might not be that easy to follow in practice). I've also included the "status" argument (bug#291148) for init scripts, and documented LSB-style status messages versus "echo" status messages.

​I'm not sure if it makes more sense to reincorporate it into the current policy document, or have it as a separate document. Seems like there are lots of independent policy documents these days (python, perl, etc), so maybe a good approach would be to compromise by keeping the separate policies as separate documents, but to package them all into debian-policy.deb...

I've kept the "musts" to a minimum -- I think it makes sense to call things RC if they're going to deadlock the system or otherwise seriously confuse init, but everything else is just a regular bug (ie "should"). Happy to change that if the release manager's think something I've missed something crucial, but fairly opposed to severity inflation otherwise. Conversely, I've left a lot of things as "should" (or "should usually") -- I think it's fair to call not supporting standard interfaces a "bug", especially given that doesn't necessarily force anyone to work on fixing it.

Anyway, corrections and additions appreciated; I'm not really an expert on init systems, so I've probably missed some bits. Upstart, and openrc and any other alternative inits could probably use some more info in particular. I had a quick go at trying to figure out what the deal with those was, but didn't really get anywhere. If anyone is up for giving a rundown of how the heck all the "non-init" systemd stuff (logind, systemd-shim, ...?) works when you're running a different init, that would probably be useful for the third section. There might be some bits where the rationale's not clear too.

I figure I'll post a patch to get this added to -policy towards the end of the week; comments before then appreciated. Either on this list or as issues (or pull requests!) in github would be best, I guess.

Cheers,
aj

--
Anthony Towns <aj@erisian.com.au>

Reply to: