Bug#835507: Please clarify that sysvinit support decision is not going to expire
On 08/28/2016 08:37 AM, Bart Schouten wrote:
> Sam Hartman schreef op 28-08-2016 1:37:
>> Similarly, if the community of people who care about sysvinit is
>> unwilling to spend the time keeping it working, eventually sysvinit
>> as a whole will be unmaintained and buggy.
>
> True, but I don't think those conditions are there.
Not yet, but a lot of sysvinit-related stuff still hasn't been
adopted after being orphaned.
> I mean that the statements:
>
> a) the scripts need (urgent) maintaining
>
> and
>
> b) in the context of the actual maintaining they do need, the help
> that is necessary isn't there.
>
> Are not true.
I would agree that in this specific case, a) is not true (there's
no apparent problem with them that wasn't already there in Wheezy),
but I'm honestly not at all sure about b).
To bring out my pet example: with sysvinit systems, in Jessie it's
not possible to have /usr on NFS anymore. The reason is that mount.nfs
is now linked against a library in /usr. I reported the bug [1] before
the release of Jessie (and I only found it because I was testing stuff
with sysvinit, I don't use it regularly at all). But nothing happened.
Then when the whole monster /usr-merge thread happened on debian-devel
half a year ago, I brought up that bug again, and nobody seemed to
care either.
With systemd this bug doesn't occur, because on systemd systems the
/usr partition is mounted in the initrd - so you can indeed boot
/usr on nfs with Jessie - but only with systemd.
To be fair: the mounting of /usr in initramfs now happens regardless
of init system also in Stretch, so the bug will now only appear if
you don't use an initramfs. But it was not sysvinit people who made
that work, but Ben Hutchings who NMU'd initscripts. [2]
Actually, the only people who appear to be improving sysvinit support
in Debian at the moment appear to be systemd users. And the only
thing I hear from sysvinit users are complaints.
> I think the "maintainership requirement" of those scripts are
> currently being exaggerated,
In this specific case? Probably. When the thread that started this TC
bug popped up on debian-devel, I was on your side: those scripts
shouldn't have been removed.
Heck, I even wrote init scripts for something I packaged recently.
(Admittedly, that was a simple daemon and the init script is trivial,
see [3].)
However, I've been working on something for the last couple of months
(on and off) to write some code to make stuff work on sysvinit for
one package I maintain, which I wouldn't need to do if I just wanted
to support systemd. Currently there's a huge workaround in the package
that is awful in every regard. And I really want to get rid of the
workaround, because it is detrimental to users in other ways (and the
workaround also affects systemd users), and do it properly.
But when I read stuff such as this:
> ... warehouse of troubles that need a million hours of employment
> each year to keep it going ...
> - you will hate the day when you discover you've been scammed ...
Or, when other people constantly and irrationally bring up
libsystemd0 again and again (see the current debian-devel thread),
then sorry, these kinds of comments make me lose any motivation in
still working on helping people out with sysvinit. It's becoming
more and more appealing to me to just say "screw sysvinit users",
I don't care anymore. I'm not there yet, but I suspect that I'm not
the only one who feels that way, so please, continue with this kind
of rhetoric, and see where you'll be at in a few years.
> Anyone writing an actual SysV init script would have thought of those
> things. That person would have felt responsible for it, because no
> one else would do it for you. That person would have built more
> intelligence into the startup script.
No, sorry, that's simply patently untrue. There are some good init
scripts out there, but the vast majority of them are just plain
horrible. They kind of work, but they make a lot of assumptions
that break in a lot of corner cases. And writing good init scripts
is _really_ hard, because shell programming is awful. (Useful, but
awful.)
Heck, even the skeleton Debian init script is completely useless
for use in a Pacemaker/HA environment - because start/stop will
_always_ return exit code 0, regardless of whether it worked or
not. (Only status returns different exit codes.) With sysvinit I
have _always_ had to patch init scripts to return proper error
codes when I wanted to use them in a HA environment. (And I've
done that since Squeeze, where there was no systemd.) This
violates LSB btw. (No, I didn't file a bug against the initscripts
package, let alone an MBF against all daemons with this problems,
not even before systemd was even a thing during Squeeze times,
because it was already very clear to me from just looking at the
bug list that nobody seemed to care about maintaining the package
properly, and I'd just be wasting my time.)
So yeah, for me sysvinit scripts are definitely no fallback. From
personal experience I am by _far_ more confident in maintainers
getting systemd services right than in them getting init scripts
right. (Obviously that doesn't mean that people don't get service
files wrong - of course that also happens from time to time.)
Regards,
Christian
[1] https://bugs.debian.org/777547
[2] https://tracker.debian.org/news/741657
[3] http://sources.debian.net/src/open-isns/0.96-4/debian/open-isns-server.isnsd.init/
Reply to: