Re: init scripts [was: If Not Systemd, then What?]
On Sun, Nov 16, 2014 at 11:50:25AM -0500, Miles Fidelman wrote:
> Given all the talk about not being able to influence upstream, it
> occurred to me to actually take a look at which of the major
> applications I rely on actually come with native systemd service
> scripts.
>
> I just went through the documentation, and in some cases, the source
> trees, for the following:
>
> bind9
> apache
> sympa
> mailman
> mysql
> mariadb
> postgres
> postfix
> spamassassin
> amavisd
> clamav
>
> Most come with sysvinit scripts, several come with their own startup
> scripts (e.g., apachectl) that get dropped into rc.local. Not a one
> comes with a native systemd service file (even though, when you
> search through the mysql documentation it tells you that oracle
> linux has switched to systemd).
>
> So... with systemd, one has to:
> - rely on packagers to generate systemd service files, and/or,
> - rely on systemd's support for sysvinit scripts, which
>
> In the later case, one just has to read:
> http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
> to get very, very scared
In practice, what would be broken ?
Taking the list :
- the fact that direct invocation is deprecated is a good thing, since
this was previously broken. Starting stuff
directly from the script mean that your environment leak in the daemon
environment, which is a source of fun bug ( like sorting in php
depending on the locale, and the locale not being always C, something
that US people tend to forget ). It also help when you are
using SELinux or another MAC, since the domain of the admin do
not leak to the daemon, and things are clearly separated.
- LSB information have to be correct anyway in Debian, or you would have bug anyway. LSB
is also old enough to have no excuse to have transitionned, and is a standard.
See https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
- timeout that would block boot are a bug, since this mean that your server could not boot
if the timeout was undefinite. Again, i can't see why a correct execution would depend on "not
booting due to 1 system blocking everything", especially in the list of service
you gave.
- again, clean env just requires you to make sure that what is needed to be set is present.
That's a question of correctness, and I think no one will advocate that being correct is
a regression.
- none of the script you gave seems interactive, and that's kinda already causing issue anyway
( for example, when automating restart accross a cluster with a tool like ansible, or when you
are not near the keyboard when the server reboot and the script start at boot ).
- additional verbs are supported on service binary, not on the script level, at least on Centos.
If that's misisng, I am sure that can be done on Debian as well, if that's not done already.
- stopping non running service seems again a weird things to do. I do not see anything that would depend
on this behavior to be correct, as that's more "we stop something that said to be stopped, but wasn't".
None of the service you gave rely on this behavior, and I would be interested into getting precise details on
what service would need this.
- run levels support is limited, but it still exist. Again, explain what is your usecase, so we can see
if that's broken or not ( because you do not test and do not give details ).
Migration to target is likely not hard ( just different directory to make symlinks ),
so i do not see why you would fear it.
- chkconfig is already returning misleading information, due to a complete lack of standard on
the return code of the initscript, despites LSB trying to clean that mess. Again, it will just
be broken in a different way. At least, mediating the interaction
with systemd make script more reliable once they use it, because there is no local variation
in return code.
- next one is again on runlevels. Please tell what local variation you have, then people can judge
if that's a reason to fear or not. Otherwise, that's just spreading FUD since most people do not
have complex runlevels systems, as "running/not running" is enough for most cases I did see.
- early boot scripts would be the biggest challenge for your setup I guess.
While you didn't gave any details , you seems to use some customs script instead of Debian, so
you would have to change that integration. Yet, without giving the usecase, no one know and maybe
I am wrong. If your setup cannot be handled by Debian regular script, maybe the Debian developpers
would be interested to fix that use case.
And last:
- no real time privs. No service you gave use that, but then there is workaround. At most 1 line to
add and a reboot. That's not what I would qualify as a cause of fear.
> Among the implications of this, the old standby of installing
> software from upstream (bypassing packaging), has just gotten a lot
> riskier.
What is the risk ? before, you were on your own, now, you would be on your own. Differences, before, you
had to write a initscript, now you have to write a initscripts or a systemd unit. Systemd unit that
even the most anti systemd person see as "not that hard to write".
What is more risky now ?
( again, the lack of details make you look like you are spreading the very definition of FUD,
and I am sure that's not what you want, so I would advice to try to avoid that if you do not
want to be labelled as hater and spreading FUD ).
--
l.
Reply to: