[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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: