On 02/10/2014 22:54, Avery Payne wrote:
Is it me, or are the Debian init.d service scripts unfortunately named?
Oh, if only it was just a naming question. But it's much more complex than that.
If the script names actually aligned with the services they controlled, we could do all kinds of things to make transitioning off of SysV easier, such as:
Yeah, unfortunately that's not going to happen. You might get close for some services, maybe even a majority, but in the general case there's no direct mapping from a System V script to a supervision run script. The supervision frameworks we have are *process* supervision frameworks. They can monitor long-running processes, and that's it. That's already great, but nowadays machine state is more complex than that. A service can be represented by something else than a process - for instance, is a network card up or down ? - and real service management is a superset of process supervision. System V init scripts do service state transition, not process state transition: you have SysV scripts to start/stop network interfaces, and they don't involve long-running processes. They don't *maintain* a state per se - they can only do transitions between "runlevels", which really are sets of service states, and they don't enforce that the running state is the wanted state at all times; but still, they manage a broader definition of "service" than just a long-lived process. And to add more complexity on top, in a SysV scheme, you can mix one-time initialization and service startup. Which is not a bad thing per se, it's sometimes needed, but this does not fit at all in a runit-like scheme where you cleanly separate the one-time initialization from the launching and supervising of the daemons. So yeah, there's no other way, for now, than doing manual conversion - you need to really study the SysV scripts to know exactly what they do, and split them into 1. one-time initialization, and 2. zero or more processes to be supervised. A lot of the time, it's going to be straightforward, but you just can't rely on it. You gave the example of Samba, but Samba isn't even that hard - it's just 2 processes. I'm sure some scripts out there are much more evil than that. In 2015, I plan to extend s6 to perform service management in a clean way. I believe it's the only way we can provide a plausible alternative to the _other_ "frameworks" out there, if you catch my drift. -- Laurent
