The Debian init system general resolution returns

Posted Oct 18, 2014 10:41 UTC (Sat) by cortana (subscriber, #24596)
In reply to: The Debian init system general resolution returns by ctpm
Parent article: The Debian init system general resolution returns

> Why the heck should the init system restart failed crashed processes?

Increased service availability.

> Who restarts init if it crashes? A trained monkey?

Hardware watchdogs can be used to reboot the system if either systemd or the kernel stop responding. You can read more about these features at http://0pointer.de/blog/projects/watchdog.html.

> If your daemon suffers from that, it should provide an overseer process.

As a sysadmin, I do not want to deal with n different implementations of service babysitters, each of which work slightly differently, and have their own bugs and configuration mechanisms. This stuff is too critical to leave to application developers.

As an application developer, I want to program to the much simpler "new-style daemons" interface described in daemon(7) rather than the "sysv daemon" interface from the same man page, because one is much quicker and easier to correctly implement than the other.

Babysitting should be done by the init system. Even Microsoft got this right with the design of the service manager in Windows NT!

> Or _you_ should use a configuration management/monitoring daemon, for which there are many to choose from today.

None of which can _really_ guarantee robustness, given that the *only* way to monitor a service properly on linux is to wait(2) on it, which can only be done to a process's children.

> Your solution is to bloat PID 1 with more mechanism and more policy, knowing there's a kernel panic if it crashes? That would be a glaring design flaw, yes. Init is engineered correctly as it is.

Please accept that these are merely your opinions. Those adopting & using systemd (and the init systems that came before it: NT's service manager, daemontools & friends, SMF, launchd, upstart) do not agree.

The Debian init system general resolution returns

Posted Oct 18, 2014 12:09 UTC (Sat) by Zack (guest, #37335) [Link] (24 responses)

> Please accept that these are merely your opinions.

Can I have that in writing? Preferably something like:

"User Zack is entitled to have opinions. As such we, systemd proponents, will not rams ours down his throat by making software he might use have a hard dependency on systemd so he will be required to accept our opinions when upgrading."

Come to think of it, that's pretty much what the proposed GR is about, isn't it? That those who for some unfathomable reason cannot see the glorious nature of systemd and all that it encompasses (and will encompass) will not be required to use it.

The Debian init system general resolution returns

Posted Oct 18, 2014 12:39 UTC (Sat) by peter-b (guest, #66996) [Link] (13 responses)

How about this? I'll enjoy my freedom to write and distribute my Free Software however the hell I want to, and you can enjoy your freedom to choose to use it (or to not use it, or to modify it) depending on how well it fits your needs.

If, in my opinion, using systemd interfaces makes my software better, then I'll enjoy the freedom to use them. And you'll have still get to enjoy the aforementioned freedoms.

You have the freedom to have whatever opinions you like. Guess what? *So does everybody else.*

The Debian init system general resolution returns

Posted Oct 18, 2014 12:58 UTC (Sat) by Zack (guest, #37335) [Link] (12 responses)

Good. I'm glad to hear you're not one of those people who don't actually use Debian but are so convinced of the righteousness of systemd they feel Debian Developers should not be given a vote to voice their opinions on the pervasiveness of their default init system.

> You have the freedom to have whatever opinions you like. Guess what? *So does everybody else.*

If only everybody else who champions systemd would feel as strongly about this you do.

The Debian init system general resolution returns

Posted Oct 18, 2014 13:06 UTC (Sat) by pizza (subscriber, #46) [Link] (11 responses)

>> You have the freedom to have whatever opinions you like. Guess what? *So does everybody else.*

> If only everybody else who champions systemd would feel as strongly about this you do.

Those who do the work, decide what gets done.

To paraphrase a saying, "Your right to hold an opinion ends when it requires me to perform unpaid work for you."

The Debian init system general resolution returns

Posted Oct 18, 2014 19:24 UTC (Sat) by Zack (guest, #37335) [Link] (10 responses)

Exactly. Thank you.

Why should I be doing unpaid work for an init system I do not want or need? It's great people like systemd and have a high opinion of it, but that opinion should really end when it's about to be installed on someone else's machine as a dependency.

The Debian init system general resolution returns

Posted Oct 18, 2014 19:50 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (8 responses)

If I followed that strictly, things like Java and Mono would never be on many of my systems. Luckily, Mono seems to be pretty stalled AFAICT, but Java is required for LibreOffice. And rewriting it in some other system is not an option. Would it make sense for me to go to LibreOffice and demand they stop using Java because I don't want it dragged in by dependencies?

And as has been linked in this article's comments already, nothing that worked with sysvinit before doesn't work now. As such, I think Lucas' amendment makes much more sense than Ian's.

The Debian init system general resolution returns

Posted Oct 20, 2014 4:24 UTC (Mon) by edomaur (subscriber, #14520) [Link] (5 responses)

Mono ? Stalled ? How ?

Anyway, as a sysadmin with a bunch of servers on Debian and RedHat EL, and I am quite happy to get systemd on both : this way, I will (probably) not needing to write the same scripts 2 time each, and I will be able to remove some complexity from my day job.

The Debian init system general resolution returns

Posted Oct 20, 2014 10:21 UTC (Mon) by Zack (guest, #37335) [Link] (4 responses)

You already had systemd on Debian, in fact, it will be the default in Jessie.

This isn't about systemd's availability in Debian, it's about preventing maintainers from deliberately stonewalling others from doing the work to keep an alternative init system usable because they are of the opinion that systemd should be the only viable option for Debian.

The Debian init system general resolution returns

Posted Oct 20, 2014 11:45 UTC (Mon) by anselm (subscriber, #2796) [Link] (3 responses)

It's about preventing maintainers from deliberately stonewalling others from doing the work to keep an alternative init system usable because they are of the opinion that systemd should be the only viable option for Debian.

AFAIK there is no evidence that this is actually a problem. Please tell me about such a case if one exists.

I don't think package maintainers will deliberately refuse to merge contributions by interested third parties that enable their packages to run with particular init systems. It's just that package maintainers should not be forcibly volunteered by third parties to come up with the required code by themselves if they don't want to (which would be against Debian's constitution).

One solution could always be to team-maintain the packages in question such that maintainer A can take care of the adaptation to init system X that maintainer B (for whatever reason) doesn't want to touch, while maintainer B maintains the adaptation to init system Y that maintainer A (for whatever reason) doesn't want to touch. On the whole, Debian package maintainers are reasonable people, and it should generally be possible to work something out.

The Debian init system general resolution returns

Posted Oct 20, 2014 13:27 UTC (Mon) by Zack (guest, #37335) [Link] (2 responses)

Not to my knowledge either, which is why there's no reason this proposal should have any influence on the release date of Jessie, and is currently a no-op. The outcome of the GR will only determine if it will remain a no-op after the release, when systemd is the default.

> I don't think package maintainers will deliberately refuse to merge contributions

And I'm not so sure about that. This GR will (or will not) give me the reassurance that any work done on alternative init implementations (or maintenance of sysvinit) will not be blocked simply by systemd being the default.

This GR isn't about shoving around work; it's about reassuring those who are not (yet) convinced about systemd, that Debian is still a suitable distribution for them and that their contributions are welcome.

The Debian init system general resolution returns

Posted Oct 20, 2014 15:31 UTC (Mon) by anselm (subscriber, #2796) [Link]

This GR will (or will not) give me the reassurance that any work done on alternative init implementations (or maintenance of sysvinit) will not be blocked simply by systemd being the default.

I think that the GR is only peripherally connected with that. As I said, even without the GR it is unlikely that package maintainers will deliberately decline to include support for other init systems than systemd if that support is volunteered by interested third parties.

It seems to me, though, that the GR in its present form tries to force package maintainers to create support for additional init systems even if the upstream package doesn't come with such support and nobody else steps forward to do it. In addition, it is unclear whether packages must support all init systems that are part of Debian or whether any two will do as long as one of them is systemd. One might also ask exactly what actually constitutes an “init system”.

In my opinion it is unreasonable to ask package maintainers to actively create support in their packages for additional non-default init systems. As of now most if not all relevant packages do support sysvinit, and that support should not be removed without good cause. Bug reports can be opened if required, and if the package maintainers don't (or can't) take care of them themselves then those people who are sufficiently interested in keeping sysvinit support going in Debian can help out. The same goes for support for things like Upstart; I don't think package maintainers should be compelled to add, debug, and maintain Upstart support for packages that don't come with it in the first place. If they want to do it, fine; but let those people who are interested in widespread Upstart support in Debian do the work if the package maintainer won't or can't do it, and have the package maintainer integrate it once it is done.

The Debian init system general resolution returns

Posted Oct 20, 2014 17:32 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

Uhm there is a whole existing workflow to overrule maintainers who are going to not take contributed patches. This GR doesn't not add to it.

What this GR does is make specific set of potential release blockers... regardless of whether patches have been contributed or not.

And let me be clear about this... this GR is not scoped to be just about ensuring a systemd transition from sysvinit.

In the future, post jesse if uselessd shows up in the repo, and uselessd works as a systemd replacement that will meet the requirement of this GR, without anything having to continue to work with sysvinit.

And that is the fundamental problem with this GR. It's not actually addressing the specific ongoing concern of making sure users can transition from old default (sysvinit) to new default (systemd) with minimal disruption.

The abstract language of the GR about init choice is just silly. Nobody really expected everything to work with mini as an alternative init without a lot of close hand-to-hand combat by the admin. The "freedom" to choose an alternative init has been until this point in time the "freedom" to break your system by choosing to use an alternative init.

This GR tries to make an overly broad policy statement that drastically changes the character of how all alternative inits are to be handled, but does not actually do anything to address the ongoing concern of transitioning from an old default init to a new default init...which is the only actionable concern that was triggered by choosing to change the default init.

-jef

The Debian init system general resolution returns

Posted Oct 20, 2014 21:29 UTC (Mon) by Wol (subscriber, #4433) [Link] (1 responses)

> If I followed that strictly, things like Java and Mono would never be on many of my systems. Luckily, Mono seems to be pretty stalled AFAICT, but Java is required for LibreOffice. And rewriting it in some other system is not an option. Would it make sense for me to go to LibreOffice and demand they stop using Java because I don't want it dragged in by dependencies?

Actually, the LO devs (and I should know, I'm involved in it) ARE rewriting LO to remove the Java dependency. Incidentally, if you do build LO --without-java, pretty much the only thing that will break is Base.

Cheers,
Wol

The Debian init system general resolution returns

Posted Oct 26, 2014 19:23 UTC (Sun) by HelloWorld (guest, #56129) [Link]

Yup, and the best they could come up with to replace Java is… Python, of all things. What a blunder!

The Debian init system general resolution returns

Posted Oct 20, 2014 0:56 UTC (Mon) by HelloWorld (guest, #56129) [Link]

Look, we've been through this. If you don't want systemd, don't use it and stick with sysvinit. But don't expect the people who maintain the software you're using to care about you if you choose to do that.

The Debian init system general resolution returns

Posted Oct 18, 2014 12:56 UTC (Sat) by cortana (subscriber, #24596) [Link] (3 responses)

Who are 'we, [the] systemd propponents'? I don't believe I have ever forced anything down your throat.

The Debian init system general resolution returns

Posted Oct 18, 2014 20:29 UTC (Sat) by jspaleta (subscriber, #50639) [Link] (2 responses)

well there was that night at the bar... and people kept buying me tequila shots and pouring them in my mouth. It's all a little hazy really.. but I'm pretty sure one of those people said a not terrible thing about systemd..which i guess makes then a systemd proponent.

-jef

The Debian init system general resolution returns

Posted Oct 21, 2014 21:33 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

So you're saying that systemd leads to drunkenness and debauchery?

And this is supposed to *dissuade* us? :P

The Debian init system general resolution returns

Posted Oct 21, 2014 21:35 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

I can't be sure about the debauchery part, as my memory is a little fuzzy due to the drunkenness.

The Debian init system general resolution returns

Posted Oct 19, 2014 15:24 UTC (Sun) by misc (subscriber, #73730) [Link] (5 responses)

Fact is simple, since contributors give for you the work they do and receive nothing from you, the power balance is utterly in their favor. They own you nothing, you own them everything they done.

Once this social dynamic is understood, you can clearly see that any user protests is going to have almost no traction, especially since that's one of the strong point of Debian, being free from pressure. A commercial distribution where you pay money would be a different beast, since the customer is listened, due to the fact he exchange money for the work, so the relationship is balanced. A community distribution, not so much.

So you decided to take a distribution where no one can influence it, so you get what you asked for

The Debian init system general resolution returns

Posted Oct 19, 2014 23:17 UTC (Sun) by jb.1234abcd (guest, #95827) [Link] (4 responses)

"Fact is simple, since contributors give for you the work they do and receive nothing from you, the power balance is utterly in their favor. They own you nothing, you own them everything they done.

Once this social dynamic is understood, you can clearly see that any user protests is going to have almost no traction, ..."

I think your interpretation of this social dynamic is lacking.
This ecosystem functions according to different laws than a commercial
organization offering a product to a paying customer.
The reason for that is obvious - Open Source Software has a participatory
and contributory character. Those active in it, whether devs or all other
people assuming formal or informal roles of users, testers, ambassadors,
commentators, etc depend on each other organically.
Many of OSS projects, including kernel, would be non-starters or suffer
quality issues without often anonymous and free code contributions, advice, discussions, and PR-like activities at home, work place, and public at large.

Now with regard to systemd.
I do not remember any software project, in this ecosystem or elsewhere,
that polarized the participants (see above) so much.
And for a good reason, as its aims as presented violated that ecosystem's
philosophy and rules of software development. It was an ambush style,
"my way or hiway" approach to introduction of a new software that impacted
everybody dependent on this ecosystem. As a result, it was met with
resistance and mistrust as to its intentions.
In the process of subsequent evaluation, the devs were even shown to lack
understanding of which domain's problems (real or perceived) they were trying to solve, which led them to a wrong model, which led them to some
antics in design and implementation.
My opinion is that systemd, if it had been properly evaluated in advance,
it would be structered and look different today, if not stopped altogether
at least until revised from top to bottom.
It is my opinion that the distros that hastily adopted systemd contributed
mightily to subsequent uproar in the ecosystem.

If systemd were not questioned the way it was (which forced the devs to
make some corrections), then the damage would be even bigger.

From this point of view alone, this Debian's GR is an attempt to limit
the damage to themselves, but also to the rest of us, and so it is
a positive step.
That's why it should find support among Debian devs, and beyond.

So, this alone invalidates your interpretation of one-way social dynamic that presumably governs relations between devs and the rest of OSS
participants.

The Debian init system general resolution returns

Posted Oct 20, 2014 11:13 UTC (Mon) by vonbrand (subscriber, #4458) [Link]

Said closed dev cabal, who you claim developed everything in a closet with no input whatsoever from the wider community, does include someone from all important distributions. Their "in a closet" development model contemplated detailed analysis of extant init systems (not only Unixy ones, BTW), careful consideration of existing configuration file formats and locations among Linux distributions, and extensive consultation with interested parties. Go check systemd's blog for development (pre)history.

The Debian init system general resolution returns

Posted Oct 20, 2014 17:45 UTC (Mon) by misc (subscriber, #73730) [Link] (1 responses)

I see almost no contribution coming from the more vocal people, and the ones that create websites are most of the time totally unknown or even hiding. There is a know harasser who is posting all over the place, speaking of suing Debian ( likely someone that didn't read the GPL ), complaining he was banned in 2006, etc.

Sure, you can think users are part of the movement and they are, but the truth is quite clear. There is no voting right for them, and they are barely acknowledge. Most distribution do not have a group dedicated to feedback from people. never wondered why there is several bug reporting tools for free software, but not so much to get feedback with a clear user orientation ?

When there is a problem, the priority is on the developer side, by pushing the work on users ( ie, filling a bug report ), because we clearly put more value on the time of people who contribute code than people that don't.

You can delude yourself in the state of free software, and I would be the first one to say that this balance of power is unfortunate and should be fixed.

Yet, being sorry about the state of affairs doesn't make it disappear, no matter how hard you want to believe. If you want things to change, you have to be constructive and do something, not just protest and post. As Linus once said "talk is cheap, show me the code".

The Debian init system general resolution returns

Posted Oct 20, 2014 20:31 UTC (Mon) by pizza (subscriber, #46) [Link]

>When there is a problem, the priority is on the developer side, by pushing the work on users ( ie, filling a bug report ), because we clearly put more value on the time of people who contribute code than people that don't.

When there is a problem, it is up to the person who finds the problem to report it. That's not "pushing work on users" or making value judgements of anyone's time.

You can't fix what you don't know is broken.

The Debian init system general resolution returns

Posted Oct 25, 2014 15:10 UTC (Sat) by ms_43 (subscriber, #99293) [Link]

The reason why systemd was started is that upstart had a fundamental design flaw requiring a substantial rewrite, and the Canonical CLA effectively prevented collaboration between the developers interested in doing that rewrite.

Instead, the systemd project was started as an open bazaar-style community without silly CLAs that give a single corporation control, and the project managed to attract many contributors (https://www.openhub.net/p/systemd/contributors/summary).

You can educate yourself by reading Scott James Remnant's comments on this post:
https://plus.google.com/+KaySievers/posts/C3chC26khpq

Thus it is hard for me to see what "philosophy and rules of software development" were violated by the systemd project.

The Debian init system general resolution returns

Posted Oct 18, 2014 15:07 UTC (Sat) by ctpm (guest, #35884) [Link] (1 responses)

>Hardware watchdogs can be used to reboot the system if either systemd or the kernel stop responding. You can read more about these features at http://0pointer.de/blog/projects/watchdog.html.

Yes, hardware watchdogs have been around for a very very long time and are obviously useful when a *kernel* stops responding or there is no process running in userspace to let you in and recover the system manually. And that is where HW watchdog use is justified -- as a last resort.

But if your failure is caused by a bug on a potentially complex thing like systemd, which could be recoverable by restarting that service alone, why would you want to bring the system down with mounted filesystems and everything? Think of a server exporting luns via network or a distributed FS shard. That spontaneous reboot may cost quite a lot in terms of recovery for the whole system. Why would you choose to nuke the system as a first option, when a least a good portion of it might be still doing useful work?

So IOW, I'm not saying that the service monitoring and recovery features on systemd are useless. I'm saying that the complex logic and state machines to handle that, should run on a child of PID 1, not in PID 1 itself.
Yes, PID 1 has the advantage of adopting every orphan in the system, but the costs of a failure can be quite high. I think a more useful approach would be to work with the kernel people to perhaps solve the waiting and re-parenting problem, instead of just overloading PID 1 and hoping for the best, and that nobody else minds about being restarted by HW watchdog. It's not like the kernel isn't already getting code whose main user will be systemd anyway.

The Debian init system general resolution returns

Posted Oct 18, 2014 18:43 UTC (Sat) by peter-b (guest, #66996) [Link]

systemd uses the hardware watchdog to check if systemd stops responding. systemd then provides watchdog functionality to services. So if a service stops responding, systemd restarts the service, and if systemd stops responding (and thus stops monitoring services), the hardware watchdog restarts the system.

I'm not sure why you consider it unreasonable to put functions for starting and monitoring services into a process that's sole role and reason for being is to start and monitor services...