Bug#835507: Please clarify that sysvinit support decision is not going to expire
Sam Hartman schreef op 28-08-2016 1:37:
I'm nervous of going too far down the path of legalisms.
Asking those who need the scripts to prove (or even say) they still
need
them is not what we want.
However if someone is having difficulty maintaining the scripts or they
are broken, it is reasonable for them to ask for help, and if no one
steps forward, eventually the scripts will become buggy enough that the
normal severity bug of a package without an init script is better than
the state of a package with a broken init script.
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.
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 think the "maintainership requirement" of those scripts are currently
being exaggerated, and if you exaggerate what is needed, you will also
look for more help than is available, and then conclude that the
community isn't there!!!!.
Don't forget that SystemD is this warehouse of troubles that need a
million hours of employment each year to keep it going, and SysV is that
small house in the desert that needs a bit of plumbing now and then for
the water that is not there (currently).
SysV didn't do all that much and so still also doesn't need to do all
that much. If anyone uses those scripts and finds they are broken, they
can fix them (for their own systems) and supply patches. If no one does,
then perhaps they still work, or the time hasn't been there for them to
be tested yet. And that time may come when it is the time for it. They
are not in harms way and they are not harming anyone.
I only mentioned the legal thing in order to stay rational:
- where is the harm in keeping those scripts around, if most systems do
not use them, and the systems that do, would be able to
change/fix/maintain them for their own, most likely.
- where is the benefit in getting rid of them, if they only achieve
people having less choice?
So there are four questions:
- qualify and quantify the benefit of not having them
- qualify and quantify the harm of not having them
- qualify and quantify the benefit of keeping them around
- qualify and quantify the harm of keeping them around.
- Surely the harm to SystemD users is minimal
- Surely the benefit to SystemD users can only be measured in more hours
of employment for SystemD people
- Surely the harm to SysV users and SystemD users alike who like having
an alternative, can be abysmally large
- Surely the benefit for them to keep them around can be substantial.
I don't see how the benefit to SystemD users can ever be called
"substantial".
Ideological, yes, but not quantifiably rational. You won't be able to
quantify those benefits.
So I say skip the qualifying and stick to the quantity.
- the only thing that can tilt that scale towards SystemD benefiting
more is if their numbers would be huuuuuuuuge compared to the SystemD
and SysV users alike who would benefit from having those scripts around.
- but just because I (for instance) qualify as a SystemD user (by
choice, or by install) doesn't mean I see any benefit in having SystemD
being the ONLY THING so please don't include me in those measurements.
- you will hate the day when you discover you've been scammed and you
need something to fall back to and it's no longer there, when it didn't
cost anyone anything to keep it around and the only dumped it so you
wouldn't have a way back.
So you must take care to ask the right questions and actually inform
with those SystemD users as to their actual opinions. Just because they
have a SystemD system installed doesn't mean they like for it being the
only thing ever.
One day you will find you need something and you'll be happy you kept it
around. That's all I can say. From life experience ;-).
If you are going to ask questions like:
- Do you feel SysV scripts are very necessary these days seeing that
SystemD handles most of everything for most applications, and most
applications have good and functioning SystemD service files?
You will get answers like "Well, maybe not. Maybe you're right."
But if you ask questions like:
- Do you feel it is important to have a fallback measure in case
something doesn't work and it is easier to make it work with a simple
SysV init script, that you would still have at your disposal?
They will say "Sure, why not. I'm all for that."
Also, SystemD often lies to you about the startup times of programs.
Often times no delay or timeout has been specified in the service file
and you think it will hang forever. The actual startup script then times
out after all, or sometimes it doesn't. SystemD often hangs for my
systems for no reason at all that I can see dismounting services that I
didn't change or do anything special to. Sometimes my system will shut
down without issue. Often times it hangs dismounting some crypt device
that it can't close because it contains the root filesystem. It does the
weirdest stuff and I don't know how to fix it, and when I try to insert
some shutdown scripts into the boot order, they appear to not to run, or
not have any effect. SystemD will complain about things not being able
to be dismounted when they have already been dismounted, or not being
able to start something when they have already been started. It doesn't
play nice with its neighbours and hardly knows what is going on. You can
try to mask services and they will still run. It will pull targets in
when it thinks it needs them regardless of what you say. I think the
requirement for having alternate scripts around is often larger than has
been anticipated, or wanted, or advised. That's just personal experience
but it is just everywhere for me. The version of SystemD that I have on
my system (229) doesn't support keyscripts. I mean, that is a big
regression. The cryptdisk scripts support it just fine and perfectly.
And then systemd-cryptsetup doesn't. How is that. Now I need to find a
way around it, and it hasn't been easy for me.
Like some funny thing. The Debian bootstrap environment for Jessie has
TTY 2-6 configured or something but in my LXC container they are not
available (5 and 6). The log files are full of getty service trying to
restart trying to achieve those tty5 and tty6.
Masking the service files doesn't help. Disabling the service doesn't
even help. Shutting down the service doesn't help. In the end I found I
needed to edit the "getty-static" service file to take those 5 and 6 out
of it.
It tries to restart every 10 seconds, indefinitely. If I hadn't been
able to edit that service file, there would have been nothing I could
do. The thing doesn't simply accept failure at some point. You can link
/dev/tty6 to /dev/null and then it will say it is not a TTY but it will
still keep restarting, because there is no intelligence in the service
file, apparently, that tells it to quit doing that, and it doesn't
"learn" from its mistakes. Then you say, well, fix it, but shouldn't
such a thing have been prevented in the first place?
There is absolutely no point in restarting them and those service files
(device files) are also not suddenly magically going to appear out of
nowhere. Bad design. Little time spent on it. It could be fixed, but not
likely, or the next thing will appear, again. Always more of those
things that need to be fixed.
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.
SystemD always functions as a kind of shield shielding your service from
the actual user. Because you have to use ready-made values and variables
in your service file, you do not actually control its operation, you
just set a few parameters. You do not do any real writing yourself.
So the opportunity for creating intelligent scripts is minimal or even
not there.
I wasted at least 20 minutes not knowing that "Waiting for Raise Network
Interfaces" (no timeout) was a lie in that it actually did timeout, but
I didn't stick around long enough to discover that. Had they not told me
that the actual script (which was SysV init script) was not going to
timeout, I would have stuck around. No information is better than bad
information.
Each time when I see that SystemD boot prompt with the "waiting
for......20 seconds / no timeout" or something like it, I am scared.
I do not know if this time it is going to hang. Sometimes the "no
timeout" is real and your system will hang forever. Often times, the
actual service does timeout, but you do not know. It scares the
jeeby-hyves out of me.
And all because it thinks it can know more about your service than the
actual writers of that service.
I wish I even could disable that prompt completely for some scripts I
have written myself.
"Waiting for..." oh shut up. Anyway, that's just a little rant from a
personal perspective. Please don't mind me too much :p.
I'm just saying that at least to my person those sysv init scripts are a
valuable asset and I cringe each time I see something disappear and I am
happy by Jessie system is still at 215 or something.
And I don't like at all the attitude of the Canonical employee that is
pushing for more integration of it and the dismantlement of the old
services.
That's all. Regards.
Reply to: