El lun., 24 dic. 2018 a las 7:10, Laurent Bercot escribió:
>
> >* https://unix.stackexchange.com/a/489949/5132
> >
> >This may be of interest to people looking for some (brief) comparative analysis. Including the further reading. (-:
>
> Thanks for the heads-up! I posted an answer in complement to yours.
>
> We really need to settle on some terminology. I don't like your
> use of "service manager" to mean "supervision system", and your use
> of "system manager" to mean what I call a "service manager" is meh.
>
> I'd be okay to ban the "service manager" terminology entirely because
> it's confusing, and use "supervision system" and "state manager" (which
> sounds better than "system manager" to me) instead. Thoughts?
I also find clearer and personally prefer the terminology used in the
skarnet.org documentation. The 'service/machine state manager' and
'process supervision suite/system' distinction captures details such
as that the former takes into account service interrelationship
(service dependency being the first form of it that comes to mind),
whereas incarnations of the latter I know of do not (by themselves).
But 'service manager' ("something that manages services") is in too
widespread use to be banned :P I have no problem with the term being
used to designate something like OpenRC or s6-rc, though.
The 'system manager' and 'service manager' terminology is used in
systemd documentation (as in "systemd is a system and service manager
for Linux operating systems", found in the man page for the systemd
program), although I don't know if the terms are given some specific
definition somewhere or just used generically.
I'm not sure that what is being described in the Stack Exchange answer
as the "system manager rôle" maps to a service manager in the s6-rc
sense. Especially the "generally is run as process #1" because "the
kernel of the operating system treats it specially, sending it
information about system state change requests" part. And the fact
that it is being applied to nosh's system-manager program and to the
van Smoorenburg init program. System state changes are mentioned, but
two aspects are involved: triggering them in response to something and
actually performing them. I read the answer as mostly referring to the
former?
I mean, with a sysvinit + OpenRC setup, it is indeed process 1, the
init program, that triggers a state change (e.g. by spawning a child
process configured in /etc/inittab in response to Ctrl + Alt + Del or
the administrator using the shutdown program), but the openrc program
that performs it (by executing service scripts in /etc/init.d). With
an s6 + s6-rc setup, it is process 1, s6-svscan, that triggers a state
change (e.g. by spanwing .s6-svscan/SIGINT or .s6-svscan/SIGUSR1
processes in response to Ctrl + Alt + Del or the administrator using
the s6-poweroff program from s6-linux-init), but the s6-rc program
that performs it. And with a nosh setup, it is process 1,
system-manager, that triggers a state change, but its system-control
child processes that perform it. Using the skarnet.org definitions,
service-manager, the program, is a process supervisor (of multiple
process rather than just one like s6-supervise, or at most two, like
runsv), and the service manager concept is implemented by
system-control :D Or rather, a subset of its subcommands that includes
'start' and 'stop'.
I'll also point out that OpenRC does have a PID 1 program since
version 0.25 named openrc-init, and an accompanying openrc-shutdown
program. BUT... it has the problem of not supervising some other
process, and therefore making the machine unusable and in need of a
reboot if all processes except #1 die. I don't know of any
distribution that doesn't use OpenRC in combination with something
else as the PID 1 program, though, at least as a supported/default
setup.
G.
Received on Mon Dec 24 2018 - 17:10:20 UTC