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
Received on Thu Oct 02 2014 - 22:55:37 UTC