|
|
Log in / Subscribe / Register

Which init system for Debian?

By Jonathan Corbet
November 5, 2013
The Debian project is no stranger to long, vehemently argued email threads, though, like the rest of us, Debian developers appear to be getting older and calmer as time goes by. If there were to be an intense thread now, one might think that the recent shift to XFCE as the default window system might be the cause. Indeed, there was some discussion of that topic, but that thread was easily buried by the hot-button issue that almost all distributions appear to need to debate at length: which init system to use. This is not the first time Debian has argued over init systems (see this 2011 article, for example), but, just maybe, it might be the last.

The job of the init system is reasonably straightforward: it is the first process that runs once the kernel boots. The init system is responsible for starting the various services that the system needs to run, preferably quickly and in the proper order. It should assist the administrator with the management of those services as the system runs, and shut things down cleanly when the system needs to go down. Traditionally, this task has been handled by a relatively simple init daemon and a large collection of service-specific shell scripts. More recently, a number of alternatives have come forward, and most distributions have either switched to one of them or plan to in the near future. Debian, however, remains with the traditional System V init system ("sysvinit") as its init system.

The process

While Debian has debated init systems (and systemd in particular) a few times in the past, the current discussion has a certain level of urgency to it. One contributing factor to this urgency is the perception that the GNOME desktop environment is developing dependencies on systemd that will make it harder to run GNOME under any other init system. Add to that an increasing sense that sysvinit is not up to the challenges of managing a contemporary Linux distribution. Finally, the current release plan calls for the "Jessie" release to be frozen in almost exactly one year; most Debian developers seem to agree that, if a change is to be made, the work needs to begin now if it is to be stable by the Jessie freeze date.

Thus, it is not surprising that the Debian community has pursued the init system debate with extra vigor this time around. The extensive discussions have made a lot of developers' opinions clear, but they have not led to any sort of consensus around which a decision can be made. When a contentious issue involves a single package, Debian has a long tradition of deferring to the package's maintainer. But no such situation holds here; instead, the debate reaches to the core of how the distribution is to be structured; it affects the design of the distribution as a whole and details in many other packages. Given the lack of consensus, it seems clear that, somehow, a decision will have to be reached by a different means.

In the past, the preferred means for reaching closure on divisive issues in Debian has been the general resolution: a vote of all Debian developers. A general resolution was duly proposed this time around as well, but the idea received little support in the end. Former project leader Stefano Zacchiroli described his opposition this way:

GRs should be used for societal and policy decisions. Using GRs for *technical* decision is stupid. We really need to stop thinking that every single member of the Debian project, just because he/she is a DD, has a clue on every single technical matter that go on in the project.

Most people seemed to agree with this position, so, at this point, it appears that no such resolution will take place. Instead, the issue has been referred to another longstanding Debian institution: the technical committee. This committee serves as a sort of high court for the resolution of technical disagreements that cannot otherwise be worked out. In general, this committee is held in high regard; its decisions command respect within the Debian community. This particular decision, though, may test just how far that respect goes.

One potential problem has to do with the membership of the committee: Bdale Garbee is the chair, while the other members are Russ Allbery, Don Armstrong, Andreas Barth, Ian Jackson, Steve Langasek, and Colin Watson. It did not take long for somebody to point out that two of those members (Steve and Colin) are current Canonical employees. Since Canonical is heavily invested in the upstart init system, it may not be unreasonable to wonder if those two members might not come under some workplace pressure to vote in upstart's favor. Given that Steve is the Debian upstart maintainer and is on record as strongly supporting that option already, there appears to be little doubt about which way his vote will go.

That said, both Steve and Colin appear to have a great deal of respect in the Debian community; both have been Debian developers for longer than they have been Canonical employees. Several other developers have expressed their belief that all members of the technical committee will approach the question with the best interests of the Debian project in mind; calls for specific members to abstain from voting on this issue have received little support.

The decision

The question is currently phrased as a choice between five options:

  1. Stick with the existing sysvinit system.
  2. Systemd
  3. Upstart
  4. OpenRC
  5. Support multiple init systems in one configuration or another

Many of the technical arguments in favor of one system or another have been heard many times before; there would be little value in rehashing them all here. For the curious, this Debian debate page is where each camp is marshaling its arguments for the technical committee; if the committee is a sort of supreme court, then that page is where the briefs are filed. Anybody who is interested in the details of each group's arguments can find them all there.

There are a couple of interesting Debian-specific issues at play here, though. One of those is tied to the fact that Debian ships distributions based on multiple kernels. The Debian GNU/kFreeBSD distribution is based on the FreeBSD kernel, while Debian GNU/Hurd uses the GNU project's Hurd kernel. Since neither systemd nor upstart supports non-Linux kernels, adoption of either of those options would create some pain for the non-Linux projects. Of the two, upstart appears to be more open to adding non-Linux support than systemd, whose developers have gone on record as being opposed to code for portability. How much that matters remains to be seen; suffice to say that opinions vary on how much influence the non-Linux ports should have on this decision.

Debian developers are also concerned about the possibility of being pushed around by other distributions. Systemd is seen by many as a Red Hat project, despite the fact that it has a significant community of contributors that reaches far beyond that company. Upstart, too, is seen as tightly tied to its corporate sponsor — a company that, in addition, is Debian's largest and most famous downstream distributor. The Debian community values its independence highly and is not afraid of charting its own path. The same mindset that leads to, say, the choice of Exim as the default mail transfer agent could encourage a choice of a less popular init system.

All of this leaves the Debian technical committee with a difficult decision. It is hard to imagine an outcome that does not leave a fair amount of unhappiness in its wake. This decision can be expected sometime fairly soon; the process of putting together the position pages appears to be about done, and the task of implementing the final decision is looking increasingly urgent. One way or another, we should soon learn how an important part of the core of the Debian Jessie release will look.

to post comments

Which init system for Debian?

Posted Nov 5, 2013 22:38 UTC (Tue) by johannbg (guest, #65743) [Link] (24 responses)

I've said it once and I'll say it again at the rate of how things are changing in the core/baseOS layer, the Debian community needs to start sticking with a single init system whatever it might be (systemd,upstart or something else ) and start working on integrating it to the best of their ability into the core/baseOS layer of the Debian distribution for their own sake thus preventing already an unmanageable situation they are dealing with from becoming even worse...

Which init system for Debian?

Posted Nov 5, 2013 23:21 UTC (Tue) by robert.cohen@anu.edu.au (subscriber, #6281) [Link] (23 responses)

Debian has a long history of choosing the wackiest option for any choice :-).
Also they clearly can't choose the same system as any other distribution.

So out of those options, I suppose openRC seems the most plausible.
Noone important uses that :-).

But I predict that they will fail to come to a consensus, and settle on a compromise solution, a dark horse candidate composed of a hand crafted set of scala scripts.

Which init system for Debian?

Posted Nov 5, 2013 23:55 UTC (Tue) by wahern (subscriber, #37304) [Link] (14 responses)

I had never heard of it, but according to Wikipedia OpenRC is already portable to non-Linux. That's definitely a plus.

People bemoan monocultures, but when it comes to writing and designing portable code all of sudden they incredulously ask, "what's it worth it me?"

Which init system for Debian?

Posted Nov 6, 2013 1:41 UTC (Wed) by josh (subscriber, #17465) [Link] (8 responses)

OpenRC is a nice improvement to init scripts themselves, by way of eliminating boilerplate, but it doesn't fix any of the core problems with sysvinit's architecture, and in particular it doesn't provide an event-based system that fits with the kernel's event-based structure. In short, OpenRC doesn't actually solve the underlying problem.

Which init system for Debian?

Posted Nov 6, 2013 11:07 UTC (Wed) by keeperofdakeys (guest, #82635) [Link] (7 responses)

As mentioned in the linked wiki, it does provide some event-based functionality, by using udev rules. No matter which system is picked though, some integration work will have to take place anyway.

Which init system for Debian?

Posted Nov 7, 2013 7:50 UTC (Thu) by ovitters (guest, #27950) [Link] (6 responses)

OpenRC doesn't provide anything that GNOME wants from systemd, like logind for instance. Suggest looking at wiki for the notes regarding systemd, the others are not that interesting as they don't solve the issue regarding ConsoleKit vs logind. Upstarts solution is to maintain a fork, not a good solution but at least it is mentioned. OpenRC: silence. That doesn't inspire confidence.

gnome?

Posted Nov 14, 2013 8:39 UTC (Thu) by amtota (guest, #4012) [Link] (1 responses)

> OpenRC doesn't provide anything that GNOME wants from systemd

Seeing how gnome seems to want to dictate everything, a little pushback sounds like positive thing to me!

gnome?

Posted Nov 15, 2013 19:04 UTC (Fri) by Company (guest, #57006) [Link]

Now, will GNOME have to do the work with Debian or will Debian have to make GNOME work?

Because that's important to figure out before you talk about who is pushing whom back.

Which init system for Debian?

Posted Nov 23, 2013 0:26 UTC (Sat) by sbergman27 (guest, #10767) [Link] (3 responses)

That might have been an important consideration for Squeeze; Gnome used to be a major player in desktop Linux. But for Jessie? I hardly see that what the Gnome guys want matters much. Debian has moved to XFCE as their default desktop. I'd be more interested in what the XFCE, Cinnamon, and MATE guys can make best use of.

Which init system for Debian?

Posted Nov 23, 2013 0:31 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

That isn't quite accurate. At this point, they haven't made any final decisions for their release yet.

http://anonscm.debian.org/gitweb/?p=tasksel/tasksel.git;a...

Note that Debian switched to Xfce before and then reverted the decision so it is unclear at this point what the release default will be. I don't think the choice of desktop environment is a big influence over the current debate however. So this is somewhat of a side discussion prompted by one of the changes.

Which init system for Debian?

Posted Nov 23, 2013 9:37 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

In an ideal world, the fact that Gnome requires systemd should make Debian's switching to it an easier decision …

Which init system for Debian?

Posted Nov 24, 2013 12:32 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

I think GNOME requires the systems DBus interface. If Debian implements it for Upstart, that should be sufficient.

Which init system for Debian?

Posted Nov 6, 2013 6:57 UTC (Wed) by epa (subscriber, #39769) [Link] (1 responses)

I think avoiding 'monoculture' is more of a Slashdot meme than a considered approach; anyone who does real work with computers understands that it is best to simplify and consolidate where possible. Then you save your intellectual firepower for the cases where a mix of different technologies is really needed.

Besides, with the global scale of Linux development, its portability to almost anything, and its scalability from tiny to huge systems, I don't think it is fair to characterize Linux as a 'monoculture'.

Linux is a monoculture?

Posted Nov 15, 2013 22:51 UTC (Fri) by Wol (subscriber, #4433) [Link]

YES IT IS!

As someone who has worked on a variety of systems (and that was before the PC/MS monoculture) I bemoan the fact that computing is now a Windows/linux duoculture.

There's an awful lot of historical viewpoints that have been swamped but imho are much better. I'm not saying the other systems are better overall, but there are lots of things where the "Unix Way" is "different".

My favourite moan is the cp command - you cannot predict FROM THE COMMAND ITSELF what the results are going to be. Can anyone predict the result of "cp a b" without knowing anything about the system it's running on? There are at least two possible outcomes depending on the environment ...

I come from a Pr1mos background - like Unix that was a Multics derivative - but it was noticeably different from Unix/Linux. Other people swear by Vax/VMS - I never used it but it had many features people liked that have been lost ...

Cheers,
Wol

Which init system for Debian?

Posted Nov 6, 2013 10:47 UTC (Wed) by drago01 (subscriber, #50715) [Link] (2 responses)

> I had never heard of it, but according to Wikipedia OpenRC is already portable to non-Linux. That's definitely a plus.

I don't think Linux development should slow down for "non Linux" operating systems to catch up. So if technology A is better then technology B but the only downside of A is that A does not work on non Linux operating systems choosing B based on that is a not great way forward.

Which init system for Debian?

Posted Nov 6, 2013 13:19 UTC (Wed) by cwillu (guest, #67268) [Link] (1 responses)

Debian is not exclusively Linux though, so yes, given their stated preferences, it is definitely a plus.

Which init system for Debian?

Posted Nov 6, 2013 16:10 UTC (Wed) by raven667 (guest, #5198) [Link]

There is already porting that needs to happen for non-Linux Debian though and unavoidable platform-specific differences between Debian on BSD, and Debian on Solaris. Like Josh said above, running launchd on BSD, SMF on Solaris and systemd on Linux makes sense as these are core technologies which are tied to and can use the unique features of the underlying kernel. This is not something which can be abstracted away without losing important capabilities. Having a different startup config file for each platform is reasonable, requiring three different startup configs for each platform is unreasonable.

Which init system for Debian?

Posted Nov 6, 2013 1:38 UTC (Wed) by pizza (subscriber, #46) [Link]

> Debian has a long history of choosing the wackiest option for any choice :-).

Yeah -- When faced with a decision, Debian inevitably goes with "All of the above."

Which init system for Debian?

Posted Nov 6, 2013 2:06 UTC (Wed) by rahvin (guest, #16953) [Link] (6 responses)

The wackiest option is going to be support all of the above and I have little doubt that they will choose to support them all. I have reasons to believe that, even though Debian on BSD and Hurd are small in comparison they will likely drive an approach that basically allows you to use any init system you want at great pain to the rest of the project.

Honestly outside Ubuntu I think every other distribution is going to end up on systemd. I even believe at some point down the road Google will shift android to it if for no other reason than continuing to lesson their development burden.

Which init system for Debian?

Posted Nov 6, 2013 13:26 UTC (Wed) by Felix (subscriber, #36445) [Link] (5 responses)

> I even believe at some point down the road Google will shift android to it if for no other reason than continuing to lesson their development burden.

Well, Google has made big strides in the past to avoid any GPL licensed code wherever they could so I'd be surprised if they start to use systemd.

Which init system for Debian?

Posted Nov 6, 2013 15:05 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (1 responses)

Like the Linux kernel you mean?

Which init system for Debian?

Posted Nov 6, 2013 15:09 UTC (Wed) by HelloWorld (guest, #56129) [Link]

The Linux kernel is pretty much the only exception. Everything else is distributed under more liberal licenses: No glibc, no udev, ...

Which init system for Debian?

Posted Nov 6, 2013 15:54 UTC (Wed) by khim (subscriber, #9252) [Link] (2 responses)

Systemd is LGPL2.1+, not GPL nowadays which makes it fair game. I'm not saying that Android will switch to it, but licensing issue is not a problem anymore: it can be used and even extended with proprietary addons if needed.

Which init system for Debian?

Posted Nov 15, 2013 20:07 UTC (Fri) by HenrikH (subscriber, #31152) [Link] (1 responses)

Sorry about the late reply but glibc is also LGPL and Google avoids it like the plague.

Which init system for Debian?

Posted Dec 3, 2013 12:42 UTC (Tue) by SEMW (guest, #52697) [Link]

Does it necessarily follow from Google's choice of bionic rather than glibc that that they "avoid it like the plague" for licensing reasons? Seems like there are technical reasons to use bionic rather than glibc in phone environments (it's much smaller, apparently works better at very low clock frequencies, etc.). Course, they *might* have chosen it because of the license, but it seems dangerous to assume political reasons for a technical choice, absent any citation.

Which init system for Debian?

Posted Nov 5, 2013 23:18 UTC (Tue) by ballombe (subscriber, #9523) [Link] (1 responses)

I do not see the TC role as making a choice between candidates. That would a political decision. Instead I expect the TC to evaluate whether

1) there is an upgrade path from sysvinit to the new system

2) whether the new system covers all the use cases that are supported by sysvinit.

3) whether the new system is compatible with packages upgrade.

etc.

Which init system for Debian?

Posted Nov 6, 2013 1:30 UTC (Wed) by zuki (subscriber, #41808) [Link]

You don't need a TC to answer those questions... Since all three contenders support init.d scripts, they all satisfy those conditions.

Which init system for Debian?

Posted Nov 6, 2013 1:46 UTC (Wed) by josh (subscriber, #17465) [Link] (6 responses)

At the moment, with the decision currently being deferred to the Technical Committee, and with several TC members already having a stated preference for upstart and a pile of complaints posted about systemd and GNOME's use of it (along with NetworkManager and other modern conveniences), I fully expect the TC to either opt for "support everything" (the current status quo) or for upstart (opting to follow Ubuntu rather than the rest of the Linux-using world).

If only the switch to XFCE by default would avoid the complaints about GNOME depending on systemd that prompted this whole mess of a discussion in the first place.

Which init system for Debian?

Posted Nov 6, 2013 6:54 UTC (Wed) by corsac (subscriber, #49696) [Link] (1 responses)

Do you honestly think changing the desktop to Xfce will change anything about this issue?

Xfce also relies on the underlying middleware for basic functions like reacting on system events (LID switch, power buttons, suspend/hibernate buttons etc).

Xfce project had a hard time keeping up with all the rewrites (hal, devicekit, upower etc.), and now that upower is dropping the support for system events (http://lists.freedesktop.org/archives/devkit-devel/2013-J...), there's not much choice than going systemd/logind, unless someone else provides some code to do that directly in the desktop.

Which init system for Debian?

Posted Nov 6, 2013 12:32 UTC (Wed) by josh (subscriber, #17465) [Link]

> Do you honestly think changing the desktop to Xfce will change anything about this issue?

I more meant that perhaps making GNOME no longer the default would give the GNOME packages more leeway to go with upstream rather than becoming an increasingly large distro fork. Then perhaps by the time XFCE started (directly or indirectly) depending on systemd as well, it would look a little more inevitable.

It took a very long time for Debian to accept dependencies on udev. It'll probably take that long again to accept dependencies on systemd.

Which init system for Debian?

Posted Nov 6, 2013 11:47 UTC (Wed) by error27 (subscriber, #8346) [Link]

Gnome (the GDM) part of gnome doesn't rely on logind (part of systemd).

http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logi...

There was a problem in openRC where it could start programs but not stop them properly. Gentoo people freaked out about it instead of fixing it. Eventually the gnome devs fixed the bug in openRC.

Which init system for Debian?

Posted Nov 7, 2013 13:43 UTC (Thu) by aba (guest, #24118) [Link] (2 responses)

I haven't see that "several TC members stated a preference for upstart". Contrary, I have seen that several TC members have asked critical questions on all init systems in question, some more technical, some more roadmap-like, some on development capacity etc, and up to now the questions regarding upstart are more critical than those against systemd. I don't think the outcome is obvious yet; contrary, it will depend much on the answers to the questions which are asked now.

Which init system for Debian?

Posted Nov 9, 2013 6:51 UTC (Sat) by lsl (subscriber, #86508) [Link] (1 responses)

> I haven't see that "several TC members stated a preference for upstart".

Considering that one TC member (Steve) is listed on the debate page as the maintainer of the upstart position statement which is accompanied by a link to a DebConf talk he (co-)held titled "Why Debian needs Upstart" I can certainly see how one would arrive at such a conclusion. ;-)

Which init system for Debian?

Posted Nov 20, 2013 18:38 UTC (Wed) by wookey (guest, #5501) [Link]

That seems more like 'one' than 'several'.

Which init system for Debian?

Posted Nov 6, 2013 4:14 UTC (Wed) by luya (subscriber, #50741) [Link] (37 responses)

kFreeBSD already has an equivalent of systemd called launchd from which upstart was made due to licensing issue at that time. Ironically, it seems the BSD communities are uninterested to adopt it.
The whole init debacle within Debian shows the complexity of adopting multiple kernels hindering the entire advance of Debian.

Which init system for Debian?

Posted Nov 6, 2013 7:50 UTC (Wed) by tzafrir (subscriber, #11501) [Link] (36 responses)

It's similar, but not compatible (likewise SMF on Solaris derivatives). "Compatible" here means that it can not use other init system's configurations (e.g.: init scripts, systemd units).

It's certainly technically feasible to ship launchd configurations for services in addition to init.d script, upstart configs and systemd units. But those are configurations that will not get properly tested (if actually written). This is even worse than the current option 5.

It seems that there's already some initial work to get upstart working in kFreeBSD (and systemd in the HURD).

See also https://en.wikipedia.org/wiki/Launchd#Use_outside_Mac_OS_X .

Which init system for Debian?

Posted Nov 6, 2013 12:36 UTC (Wed) by josh (subscriber, #17465) [Link] (35 responses)

Actually, I think having packages support both systemd and launchd would be far more sensible than supporting both systemd and sysvinit. Use the most capable native init system on each platform, and let the porters for each platform support and maintain any of the pieces the maintainer doesn't.

(Bonus if the packaging occurs separately: each random daemon could depend on that-daemon-launchd only on kfreebsd, allowing maintenance of that scripting in a separate package.)

Which init system for Debian?

Posted Nov 6, 2013 13:20 UTC (Wed) by tzafrir (subscriber, #11501) [Link] (34 responses)

Currently packagers are encouraged to support init.d, upstart and systemd. Adding launchd (which will only get tested on a certain[0] fringe platform) to the mix will only cause lots of work with no noticeable gain. Is launchd really better than upstart (which has actually been properly integrated)?

per-architecture Maintenance of packages is frowned upon in Debian as it doesn't scale. In practice it would mean that most packages will not Just Work[tm] on kFreeBSD.

[0] well, technically there are two: mfreebsd-i386 and kfreebsd-amd64.

Which init system for Debian?

Posted Nov 6, 2013 14:02 UTC (Wed) by josh (subscriber, #17465) [Link] (33 responses)

> Currently packagers are encouraged to support init.d, upstart and systemd. Adding launchd (which will only get tested on a certain[0] fringe platform) to the mix will only cause lots of work with no noticeable gain. Is launchd really better than upstart

upstart doesn't currently run on kfreebsd; better to support the native init system for that platform than port a new one. And no, supporting sysvinit, upstart, systemd, and launchd would be a bad idea. Supporting systemd and launchd, on the other hand, would be an improvement over supporting systemd and sysvinit (with the latter kept around for the benefit of kfreebsd).

Which init system for Debian?

Posted Nov 7, 2013 7:59 UTC (Thu) by dgm (subscriber, #49227) [Link] (32 responses)

> upstart doesn't currently run on kfreebsd;

Neither does systemd.

The question is: is upstart portable to kfreebsd? Because if it is, then it puts upstart in a much better position to be the init that will rule them all. I assume that porting upstart is less work than introducing (and keeping) launchd in the long run. I guess an essential question is if upstart developers are willing to do the port. Knowing they are already part of Debian and actively proposing upstart, I guess they are. But better ask them, and by the way, ask them if it's their intention to maintain upstart even in the case their corporate overlord changes plans.

Which init system for Debian?

Posted Nov 7, 2013 12:41 UTC (Thu) by HelloWorld (guest, #56129) [Link] (29 responses)

> I assume that porting upstart is less work than introducing (and keeping) launchd in the long run.
I doubt that. systemd offers a ton of features that people want and that Upstart doesn't have: cgroup arbitration, resource management, logind, kdbus, syscall filtering, capability management and a lot more. Choosing Upstart means that they'll have to develop and maintain this by themselves (or get Canonical to do it), and that's a ton of work. I don't see that happening, and thus I won't be using Debian in the future if they actually go with Upstart. Because I, like 99% of all Debian users, don't care about the kFreeBSD or Hurd ports. Others seem to agree with that:

http://lists.debian.org/debian-ctte/2013/11/msg00011.html

Picking anything other than systemd would be a huge mistake both for the debian project and for the Linux ecosystem as a whole.

Which init system for Debian?

Posted Nov 7, 2013 15:02 UTC (Thu) by Seegras (guest, #20463) [Link] (1 responses)

> I, like 99% of all Debian users, don't care about the kFreeBSD or
> Hurd ports.

I don't use them, BUT ports are always a good idea to find bugs. And insofar, I care about them.

More interesting than different kernels are however different architectures. Debian ARM does much more to find bugs than Debian/Hurd does (and Hurd only runs on i386 anyway).

Which init system for Debian?

Posted Nov 7, 2013 21:05 UTC (Thu) by HelloWorld (guest, #56129) [Link]

> I don't use them, BUT ports are always a good idea to find bugs.
I disagree. Probably most of the bugs that are found by porting to other platforms only affect that platform or abstraction layers that only exist to make the software portable. I also think it's more efficient to spend time on dedicated debugging measures (code review, valgrinding, bug triaging etc.) than to spend it on a new port that nobody actually uses in production and hope for bugs to be eliminated as some sort of side effect.

Which init system for Debian?

Posted Nov 7, 2013 15:08 UTC (Thu) by dgm (subscriber, #49227) [Link] (18 responses)

> systemd offers a ton of features that people want and that Upstart doesn't have

And that are not provided by the current default init system either. And we somehow have managed to live without them so far.

> I won't be using Debian in the future if they actually go with Upstart.

That would not be very rational. To start, I think changing the default does not preclude from having options. Both Upstart and systemd are available right now, for instance.

Anyway, any option chosen will be an step ahead, even if it isn't the option with more features. Simplicity is also a very good quality to have in such a central piece of the system.

> I, like 99% of all Debian users, don't care about the kFreeBSD or Hurd ports.

But you should. For the same reasons you should care about processors other than x86, form factors other than desktops, and OSes other than Windows (that's what most people use, after all).

Which init system for Debian?

Posted Nov 7, 2013 16:51 UTC (Thu) by andreasb (guest, #80258) [Link]

>> I, like 99% of all Debian users, don't care about the kFreeBSD or Hurd
>> ports.

> But you should. For the same reasons you should care about processors
> other than x86, form factors other than desktops, and OSes other than
> Windows (that's what most people use, after all).

Well, 99% of all Debian users don't care about m68k. And so the port was dropped from the archive years ago when it couldn't keep up instead of holding back kernel, libc and toolchain versions, Debian freezes/releases and whatnot. Same for alpha and hppa.

Yet people argue that kFreeBSD and Hurd require all of Debian to bend over backwards to support them no matter the cost.

Which init system for Debian?

Posted Nov 7, 2013 22:13 UTC (Thu) by HelloWorld (guest, #56129) [Link] (16 responses)

> And that are not provided by the current default init system either. And we somehow have managed to live without them so far.
Yeah, and my grandma somehow manages to live with no computer at all. What kind of argument is that supposed to be?

> Anyway, any option chosen will be an step ahead, even if it isn't the option with more features. Simplicity is also a very good quality to have in such a central piece of the system.
The need for complex features doesn't simply go away when your init system doesn't offer them, the complexity is simply shifted elsewhere. This is a common phenomenon that is expressed, among others, in Greenspun's tenth rule of programming.

> But you should.
I don't think that's for you to judge.

Which init system for Debian?

Posted Nov 11, 2013 14:23 UTC (Mon) by dgm (subscriber, #49227) [Link] (15 responses)

> The need for complex features doesn't simply go away when your init system doesn't offer them

You realize there's a difference between "need" and "want", don't you?

> I don't think that's for you to judge.

My opinion is completely for me to judge.

Which init system for Debian?

Posted Nov 11, 2013 15:45 UTC (Mon) by HelloWorld (guest, #56129) [Link] (13 responses)

> You realize there's a difference between "need" and "want", don't you?
It doesn't matter at all. Just replace "need" with "demand" in my comment, that doesn't change the essence of the point I'm making. People want it, and if they don't get it from debian, they'll get it from somewhere else.

> My opinion is completely for me to judge.
It's none of your business what I should or shouldn't care about. Of course you're entitled to your opinion, but that doesn't mean you have to tell the world about it, and you're being a smart-arse if you do.

Which init system for Debian?

Posted Nov 11, 2013 22:14 UTC (Mon) by dlang (guest, #313) [Link] (7 responses)

>> My opinion is completely for me to judge.

>It's none of your business what I should or shouldn't care about. Of course you're entitled to your opinion, but that doesn't mean you have to tell the world about it, and you're being a smart-arse if you do.

similarly, you can't say that "everyone needs this" or "everyone wants this" when there are people who are saying that they are happy without this.

Nobody is saying that systemd shouldn't be an option for the people who want it. The only thing that people are objecting to is being forced to switch distros to avoid using systemd when they don't want it.

and the statement from Lennart that systemd is not an init system, it is a set of "components needed to build up an operating system on top of the Linux kernel" don't make people happy who want to run a Unix OS instead of a Lennart OS. Again, they don't object to people who want to run LennartOS having that ability, they object to distros being chnaged from Unix to LennartOS while keeping the same name (if you think about this a bit, it's exactly the same objection people have to Gnome3 being so completely different than Gnome2 but keeping the same name)

Which init system for Debian?

Posted Nov 11, 2013 23:29 UTC (Mon) by anselm (subscriber, #2796) [Link] (6 responses)

The only thing that people are objecting to is being forced to switch distros to avoid using systemd when they don't want it.

Other people object to being forced to switch distros to get systemd by default when they do want it, when essentially all other distributions of note are using it by default, too – rather than having to patch it into Debian after the fact just to keep a small percentage of users on the fringe happy.

they object to distros being chnaged from Unix to LennartOS while keeping the same name

The funny thing is how, by and large, the actual Unix OSes have quietly moved over to using other init systems. This should tell us something about the continuing viability (or lack of such) of System-V init, and the sense (or nonsense) of trying to hang on to it at all costs, just for old times' sake. We have made all sorts of other sweeping changes to Linux over the years without bothering to change the name, so claiming that changing the init system suddenly makes Linux into a different operating system seems a bit contrived.

Anyway, after 30 years or so of SysV init, it makes sense to look for a replacement that is up to handling the fact that today's Linux computers, on the whole, do not look like a DEC VAX with two dozen terminals. Various such replacements have been proposed. In my opinion it makes sense for Debian to put the question of which init system should be Debian's default before the TC; we can only hope that this question will be debated on the technical merits of the proposals rather than propaganda and FUD, and that whatever decision is eventually taken will be supported by all the camps in question.

Which init system for Debian?

Posted Nov 12, 2013 3:14 UTC (Tue) by dlang (guest, #313) [Link] (5 responses)

Debian already allows you to use systemd if you want.

As for other distros that don't want to offer multiple options, I would say that people who want something not in their distro are the ones who should change to a different distro rather than the ones who want things to keep working.

your positioning of people who are happy with things as they are as the 'fringe' is not conclusive to calm discussion

Which init system for Debian?

Posted Nov 12, 2013 9:55 UTC (Tue) by anselm (subscriber, #2796) [Link] (4 responses)

Debian already allows you to use systemd if you want.

Yes, and if the Debian TC decides to make systemd or Upstart the default on Linux, Debian will probably still allow you to use SysV init if you want.

I would say that people who want something not in their distro are the ones who should change to a different distro rather than the ones who want things to keep working.

I think that if Debian does decide to change its default init system there will be a huge emphasis on »keeping things working«. Systemd, for example, can deal with SysV init scripts; you just lose some of systemd's special features for those services.

your positioning of people who are happy with things as they are as the 'fringe' is not conclusive to calm discussion

The »people on the fringe« are those who believe that the mere existence of Debian on a FreeBSD or Hurd kernel entitles them to dictate policy to the project as a whole.

It's great if people are »happy with things as they are«. However, progress marches on, and Debian as a project must figure out how to deal with this. Possibly after a transition to a more modern init system, as many (or more) people will be as happy (or even happier) with things as they are then. That there are people who are happy with the current setup today should not act as an automatic barrier to well-reasoned change.

In other words, I'm sure that in the past there were lots of people who were blissfully happy with things like a.out binaries, libc5, or a static /dev directory, but even so the Debian project decided to go with ELF, glibc2, and udev, and by now there is fairly general consensus that these were reasonable decisions. It is very likely that if Debian does decide to go with systemd as the default init system on Linux even in the face of vociferous objections from those people who still like SysV init, a few years from now we will look back and consider that decision reasonable, too, in the grand scheme of things. Fondly remembering the old days when we managed to get by with simpler approaches to many things does not preclude embracing new and better solutions that are designed to deal with today's (or even tomorrow's) challenges.

Which init system for Debian?

Posted Nov 12, 2013 10:18 UTC (Tue) by dlang (guest, #313) [Link] (3 responses)

> I think that if Debian does decide to change its default init system there will be a huge emphasis on »keeping things working«

This is one of the things I trust Debian (and Gentoo) to do well, they provide options rather than picking the 'one true way'

I would not be thrilled if Debian were to pick systemd as the default, but as long as it remained a requirement that packages work without systemd, it would only be a mild annoyance (very similar to their use of Grub while I still prefer lilo in most cases)

It would only be if they started allowing systemd-only packages as something other than a very rare case that I would have a problem with it.

Which init system for Debian?

Posted Nov 12, 2013 10:42 UTC (Tue) by anselm (subscriber, #2796) [Link] (1 responses)

I would not be thrilled if Debian were to pick systemd as the default, but as long as it remained a requirement that packages work without systemd, it would only be a mild annoyance

Personally I wouldn't want to bet the farm on this. Your best hope is that the non-Linux Debian platforms will stick with SysV init, and that some support for SysV init remains in Debian policy to cater to those.

Speaking as a Debian developer, one enticing advantage of systemd is no longer having to write SysV init scripts, so I would hope that the Debian policy requirement to do so will eventually go away, or that at the very least we will come up with a way of automatically creating SysV init scripts from systemd unit files. I seem to remember that this is being looked at, and if Debian does decide to go with systemd, I would certainly expect the vocal SysV init aficionados to contribute heavily to that effort.

Which init system for Debian?

Posted Nov 12, 2013 13:02 UTC (Tue) by HelloWorld (guest, #56129) [Link]

You probably mean this:
https://github.com/akhilvij/systemd-to-sysvinit-converter
That project seems to have gone dormant about a year ago.

Which init system for Debian?

Posted Nov 20, 2013 22:53 UTC (Wed) by josh (subscriber, #17465) [Link]

The whole point of switching to systemd would be to throw away piles of ugly compatibility code to try to keep things like (the unmaintained) ConsoleKit limping along.

There's an option under consideration to keep multiple options; that'd be better than sticking with sysvinit for all eternity, but ideally I'd like to see a switch to systemd with sysvinit script compatibility as the default option, thus allowing software to depend on it.

It'll then be up to people who want to keep other init systems going to submit patches supporting them; it shouldn't be the job of every maintainer of software whose upstream relies on systemd to fork it and remove that dependency. If someone wants that, they should "fix" it upstream or fork the project themselves, rather than making Debian do it.

Which init system for Debian?

Posted Nov 13, 2013 17:38 UTC (Wed) by ThinkRob (guest, #64513) [Link] (4 responses)

> People want it, and if they don't get it from debian, they'll get it from somewhere else.

Some developers and power users do.

Users wants systems that boot quickly (for varying definitions of quickly), and work reliably.

Personally I believe that the users' requirements can be (and in the past have been) met without systemd. The power users/developers, on the other hand? Tthey want systemd in part because it's new and cool, and playing with new and cool tech is... well... cool.

Which init system for Debian?

Posted Nov 13, 2013 19:28 UTC (Wed) by smurf (subscriber, #17840) [Link] (3 responses)

Don't talk about reliability. Without socket activation I cannot reliably restart a service. Just as one example.

I don't want systemd because it's new and cool. I want it because with systemd I can forget about complex nonsense in the stuff I do care about.

For instance, my daemon process doesn't have to go through the rigmarole of double-forking, detaching from the terminal, cleaning up its environment, etc., any more. This is easy to get wrong. Esp. when a library writes its error messages to STDERR … which daemonizing redirets to /dev/null. Ouch.

I can use journalctl. That gives me the output I care about in exactly one place. This makes my job of debugging programs easier. This makes for more reliable programs. This benefits "normal" users.

I can restart a socket-activated process seamlessly. This benefits normal users because their system is no longer in a semi-reliable in-between state when they upgrade it.

I can give daemons their own /tmp, restrict them from looking at users' /home, and whatnot. Granted that this can be done with some sort of helper program, but with systemd's config files this sort of thing is so simple that it's actually going to be used. (And it's faster.)

And so on.

Which init system for Debian?

Posted Nov 13, 2013 20:27 UTC (Wed) by raven667 (guest, #5198) [Link]

> For instance, my daemon process doesn't have to go through the rigmarole of double-forking, detaching from the terminal, cleaning up its environment, etc., any more. This is easy to get wrong. Esp. when a library writes its error messages to STDERR … which daemonizing redirets to /dev/null. Ouch.

I run into this all the time because most of our locally generated software is perl written by people who's primary job isn't systems programming so I have to try and fix it in shell using nohup and shell job control and whatnot, getting scripts to set their $0 so that I can use pidof to identify and restart them (instead of having everything be /usr/bin/perl). All of this hoop-jumpery doesn't feel like well thought through design, it feels hacky and hokey whereas systemd seems well thought through, well documented and thorough. You can read through the design philosophy and process in the blog posts at 0pointer.de and judge whether they make sense to you, they certainly made sense to me and seem an improvement on daemontools or runit in every way.

Which init system for Debian?

Posted Nov 19, 2013 5:57 UTC (Tue) by ThinkRob (guest, #64513) [Link] (1 responses)

> I don't want systemd because it's new and cool. I want it because with systemd I can forget about complex nonsense in the stuff I do care about.

That's kinda my point. You're a power user. You write your own init scripts.

Most users don't. Most probably never will.

For them, it doesn't really matter if their distros' maintainers had to jump through a bunch of hoops to make sysvinit work.

I'm glad you like systemd. It's got a lot of cool tech in it, and while I'm not sold on it being made a key part of peoples' security strategies, I do think it's good at handling a lot of, well, system tasks. But I'm also not a normal user, so I'm with you in that segment of the community that likes things that offer neat features to developers and sysadmins. I just don't think that my views are majority opinions, that's all.

Which init system for Debian?

Posted Nov 19, 2013 9:17 UTC (Tue) by smurf (subscriber, #17840) [Link]

> That's kinda my point. You're a power user. You write your own init scripts.

I don't. Not any more. And that's a good thing.

I just fail to see any advantage of staying with sysV, for any use case. Other than "hey diversity" or "hey kFreeBSD/Hurd", both of which I frankly do not care about at all, because (a) I propose to be diverse in the areas that actually matter to users and their use cases instead of infrastructure that makes programs more difficult to install and maintain, and (b) the number of kFreeBSD or Debian/Hurd users is, frankly, so small that forcing a suboptimal init system on the rest of Debian ultimately wastes more man-hours than the productive uptime of all these systems combined. :-P

Seriously, also shipping rudimentary sysV init scripts for these systems is not going to be a problem. Or take much effort. If any.

Which init system for Debian?

Posted Nov 15, 2013 23:01 UTC (Fri) by Wol (subscriber, #4433) [Link]

Well, something I "need" is multi-head. That is, having two monitors, keyboards, mice and users on the same machine. At present, with just one video "card" I gather that's impossible.

Systemd, however, will soon be providing that by default. Which means I might have to swap my gentoo install over from OpenRC - I'm not looking forward to it.

THAT is the sort of complexity that presumably is needed in the startup system - I presume that is everything that happens before user login, no?

Cheers,
Wol

Which init system for Debian?

Posted Nov 10, 2013 14:11 UTC (Sun) by Jandar (subscriber, #85683) [Link] (3 responses)

> systemd offers a ton of features that people want and that Upstart doesn't have: cgroup arbitration, resource management, logind, kdbus, syscall filtering, capability management and a lot more.

And there are many people who don't want all of this forcible managed by a monolith at the core of the system.

The features of systemd are nice but this overarching greedy tentacle-monster is terrifying.

Which init system for Debian?

Posted Nov 10, 2013 17:41 UTC (Sun) by raven667 (guest, #5198) [Link]

> systemd are nice but this overarching greedy tentacle-monster is terrifying

I just can't get there man, all systemd is doing is exposing all of the existing configuration knobs for starting processes that the Linux kernel has accreted over the last decade in a consistent way. Those features and the complexity around them don't just go away if the init system doesn't support them, it just gets pushed into other tools that aren't integrated well. I don't find that terrifying, I'm relieved and glad that I can finally find and use these kernel features, and that the standard for process management has finally moved past pid files and super-hokey scripts. I guess I was spoiled all those years with daemontools.

Which init system for Debian?

Posted Nov 10, 2013 20:07 UTC (Sun) by khim (subscriber, #9252) [Link]

Once opon time the same thing was said about Linux itself. Remember the infamous Microkernels have won tirade?

Systemd looks like a repeat of the same story: sure it's theoretically nice to have many small packages instead of one large package, but in practice it just makes no sense. What difference does it make if error in any one of these can give you root access? Useless frictions on the boundaries between packages?

Once upon time GNU has fileutils, shellutils, and textutils. Not they have combined it all in coreutils. Systemd does the same to set of utilities dedicated to the system startup. It does not merge tham into a huge monolythic monster, instead it offers a collection of well-integrated utilities when each one does few things and does them well. It's core is large for the same reason Linux core is large: many things are just hard too pull of if you don't control PID 1. You can kinda make them work but not reliably, you can introduce interface between PID 1 and other utilities, but if there will be exactly one consumer for the interface it'll just complicate everything without giving anyone any real benefits.

Which init system for Debian?

Posted Nov 10, 2013 20:07 UTC (Sun) by khim (subscriber, #9252) [Link]

Once opon time the same thing was said about Linux itself. Remember the infamous Microkernels have won tirade?

Systemd looks like a repeat of the same story: sure it's theoretically nice to have many small packages instead of one large package, but in practice it just makes no sense. What difference does it make if error in any one of these can give you root access? Useless frictions on the boundaries between packages?

Once upon time GNU has fileutils, shellutils, and textutils. Not they have combined it all in coreutils. Systemd does the same to set of utilities dedicated to the system startup. It does not merge tham into a huge monolythic monster, instead it offers a collection of well-integrated utilities when each one does few things and does them well. It's core is large for the same reason Linux core is large: many things are just hard too pull of if you don't control PID 1. You can kinda make them work but not reliably, you can introduce interface between PID 1 and other utilities, but if there will be exactly one consumer for the interface it'll just complicate everything without giving anyone any real benefits.

Which init system for Debian?

Posted Nov 14, 2013 7:22 UTC (Thu) by kevinm (guest, #69913) [Link] (3 responses)

Debian is used a great deal on servers, where most of those features (and hell, GNOME) are surplus to requirements. sysvinit is still the most appropriate in that environment.

(syscall filtering should be setup in the individual apps, by the way).

Which init system for Debian?

Posted Nov 14, 2013 8:30 UTC (Thu) by khim (subscriber, #9252) [Link]

Really? Recall that it's ability to kill and restart services and indeed, the whole underlying infrastructure (cgroups) were designed specifically for server needs, they were adopted by Gnome only later. Recall that all "big" UNIXes switched to custom-made init systems for more-or-less the same reason even if they no longer viable on desktop (indeed sales of UNIX workstations have ended) and it'll become obvious that even on servers systemd makes perfect sense.

kFreeBSD or Hurd, on other hand... have anyone ever seen them used on server in production?

Which init system for Debian?

Posted Nov 15, 2013 6:38 UTC (Fri) by smurf (subscriber, #17840) [Link] (1 responses)

Yeah, sure. Like "seamless server restart" or "integrated logging" or "private /tmp for services" is of much use for workstations, which typically don't run more than five server-type jobs (ntp, system-dbus, networkmanager, acpi, cups).

Go through the list of systemd's features sometime, and then tell us honestly which are more appropriate for workstations vs. servers.

SysV "server management" can still mostly be replaced with a linear list of command lines. systemd cannot.

Which init system for Debian?

Posted Nov 16, 2013 20:50 UTC (Sat) by kleptog (subscriber, #1183) [Link]

SysVinit is not really good enough for servers either. In my experience daemontools is a lot more functional, in that it actually tracks when processes die and restarts them. It also provides a way to capture the log output.

By all accounts systemd will do an even better job, though I've not had the opportunity to find out yet...

Which init system for Debian?

Posted Nov 7, 2013 13:49 UTC (Thu) by josh (subscriber, #17465) [Link] (1 responses)

> Neither does systemd.

I never said it did; it makes more sense to use the most capable native init for each platform than to force one less capable init system across the board in the name of portability.

Hence systemd for Linux and launchd for kfreebsd.

Which init system for Debian?

Posted Nov 7, 2013 14:55 UTC (Thu) by dgm (subscriber, #49227) [Link]

There are a lot of things that make sense, it all depends on your priorities.

Which init system for Debian?

Posted Nov 6, 2013 7:06 UTC (Wed) by ncm (guest, #165) [Link] (6 responses)

How mature is the Debian systemd package? Can I try it out without taking foolish risks? Supposing Debian were to decide for OpenRC, would there be any difficulty for users running OpenRC, Upstart, or SysVinit instead? I.e., is this just about project defaults, or does it profoundly change packaging policy?

Which init system for Debian?

Posted Nov 6, 2013 7:08 UTC (Wed) by ncm (guest, #165) [Link]

That's "... running Systemd,...".

Which init system for Debian?

Posted Nov 6, 2013 7:30 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

It's OK.

I'm using systemd on my Debian on RaspberryPi to speed up the boot (it really needs it...). I think I had to tweak cgroups kernel options in GRUB, but that's it. Everything else works fine.

Which init system for Debian?

Posted Nov 6, 2013 12:47 UTC (Wed) by KSteffensen (guest, #68295) [Link]

Works pretty much out of the box on my Dell XPS13. There was a conflict with the sysvinit package but I haven't seen it complaining on my last few runs of apt-get dist-upgrade so it may have been resolved now.

More info here:
https://wiki.debian.org/systemd#Issue_.231:_sysvinit_vs._...

Which init system for Debian?

Posted Nov 6, 2013 19:43 UTC (Wed) by rbrito (guest, #66188) [Link] (2 responses)

If your system has a moderately current sid installation (I am not sure if testing has it), then the bulk (all?) of systemd is already installed and trying to use systemd for one boot is as simple as passing

init=/bin/systemd

on the kernel command line (i.e., as an option in your bootloader).

One thing: yes, that's /bin, BTW, not /sbin.

I am, by the way, with my computer booted right now with systemd and, so far, I have not seen any differences regarding the regular sysv init system, apart from a bunch of pseudo-filesystems mounted under /sys/fs/cgroup (and probably some others).

Which init system for Debian?

Posted Nov 21, 2013 13:59 UTC (Thu) by mirabilos (subscriber, #84359) [Link] (1 responses)

Well, everyone knows that Poettering is too stupid to put his crap anywhere than into /bin (or /usr/bin if /bin points there).

Which init system for Debian?

Posted Nov 21, 2013 15:06 UTC (Thu) by corbet (editor, #1) [Link]

Oh please, this isn't kindergarten; can we please find a way to do without the silly personal attacks?

Can we have a discussion based on fact, please ?!

Posted Nov 6, 2013 8:29 UTC (Wed) by dambacher (subscriber, #1710) [Link] (2 responses)

Given the ferrocious and sometimes hateful discussion happening in gentoo at the moment, maybe the Debian Technical Comitee debate files give a more "grounded" fact based view on the different features and implications.
This would be a benefit for the whole *nix community!

Maybe the next thing to discuss is if we stick to the filesystem hirarchy standarts with /bin /sbin /usr/bin and usr/sbin cleanly divided and the implications of not depending on /usr/* at boot time.

/usr and boot-time

Posted Nov 6, 2013 9:55 UTC (Wed) by hmh (subscriber, #3838) [Link]

Debian solved that one the easy way: the supported options are a separate /usr mounted by the initramfs, or no separate /usr at all. Separate /usr without initramfs, for example, is not supported and things are going to be allowed to break in that case.

So, as far as Debian is concerned, the /usr/*bin versus /*bin, and bin versus sbin issues will become purely namespace issues.

Can we have a discussion based on fact, please ?!

Posted Nov 6, 2013 12:25 UTC (Wed) by ovitters (guest, #27950) [Link]

The only thing you need for a separate /usr is a initramfs. This was mentioned as a requirement in one of those Gentoo NEWS files quite recently. Gentoo like to discuss for ages before rediscovering that the suggested solution was actually not that bad :P

Not aware of any hateful discussion in Gentoo. I do see various Gentoo users raising the same things over and over again.

Dependency on systemd: why/where?

Posted Nov 6, 2013 12:37 UTC (Wed) by jfasch (guest, #64826) [Link] (9 responses)

I did some research on why systemd has become a hard dependency for GNOME, but haven't come with anything but https://mail.gnome.org/archives/desktop-devel-list/2012-N.... That issue has been resolved a year ago.
Can anyone point me to an answer please?

Dependency on systemd: why/where?

Posted Nov 6, 2013 13:58 UTC (Wed) by zuki (subscriber, #41808) [Link] (5 responses)

It uses systemd-logind's dbus interfaces to control suspend, hibernate, and session switching.

Dependency on systemd: why/where?

Posted Nov 6, 2013 18:00 UTC (Wed) by debacle (subscriber, #7114) [Link] (4 responses)

Speaking out of absolute ignorance, here, but how hard is it to define a DBus interface for such tasks, that can be implemented by any init system? So that Gnome would depend on a well-defined interface, not on a specific program? Both systemd and upstart are using DBus anyway and for others a simple bridge could be build. What am I missing?

Btw: I'm using upstart on a huge number of Debian Squeeze(!) systems and it works well for my task. I would not oppose to systemd, however - as long as we get rid of sysvinit, RSN.

Dependency on systemd: why/where?

Posted Nov 6, 2013 18:13 UTC (Wed) by ovitters (guest, #27950) [Link]

Actually, GNOME depends on the d-bus interface. What we don't want is several different APIs. E.g. different d-bus interfaces and so on.

Dependency on systemd: why/where?

Posted Nov 6, 2013 19:08 UTC (Wed) by alexl (guest, #19068) [Link]

Here is that dbus interface:
http://www.freedesktop.org/wiki/Software/systemd/logind/

Its on a page with "systemd" in the name, but the API is generic.

Dependency on systemd: why/where?

Posted Nov 8, 2013 18:54 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

> Speaking out of absolute ignorance, here, but how hard is it to define a DBus interface for such tasks, that can be implemented by any init system?

The problem isn't the interface.. it's dbus already.

The problem is that no other init system is going to provide the features needed.

Ubuntu forked logind, but they are going to have a VERY hard time keeping up with systemd.

Dependency on systemd: why/where?

Posted Nov 9, 2013 7:51 UTC (Sat) by tzafrir (subscriber, #11501) [Link]

"Forked" also implies that their patches were not accepted.

Up until systemd 204, their patch was pretty simple: just keep logind separate. In systemd 205, systemd is now the sole cgroups controller. This means that a separate session logind no longer implements that functionality.

At the moment their direction seems to be to adapt Google's lmctfy (LM contain TFY - https://github.com/google/lmctfy/ - originally intended for containers) as the cgroups controller.

Dependency on systemd: why/where?

Posted Nov 6, 2013 15:08 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (2 responses)

It has only become a hard dependency if you configure it for systemd support instead of ConsoleKit. But on Linux the default is to configure it for systemd.

Dependency on systemd: why/where?

Posted Nov 6, 2013 15:30 UTC (Wed) by avheimburg (guest, #75272) [Link]

Well, given that ConsoleKit is no longer maintained in favor of systemd-logind according to

http://www.freedesktop.org/wiki/Software/ConsoleKit/

it looks like systemd will be the way to go if you want a nice, integrated FOSS desktop. That or reimplement a lot of infrastructure.

Dependency on systemd: why/where?

Posted Nov 6, 2013 15:31 UTC (Wed) by jfasch (guest, #64826) [Link]

Thank you for the explanation. Makes sense for GNOME to take this functionality (suspend etc.) from where it belongs, rather than building it into the desktop.

Which init system for Debian?

Posted Nov 6, 2013 17:52 UTC (Wed) by jengelh (subscriber, #33263) [Link]

>Since neither systemd nor upstart supports non-Linux kernels, adoption of either of those options would create some pain for the non-Linux projects. Of the two, upstart appears to be more open to adding non-Linux support than systemd, whose developers have gone on record as being opposed to code for portability.

Well, IIUC, patches are acceptable—iff the other target platform supported the fancy features (like cgroups), which they do not at this time. Plus, were the BSDs to have something cgroup-like, they probably would not implement the same API, and that might be the showstopper to accepting patches. (And then there is the license question… neither upstart nor systemd are BSD-licensed, so they would not take it.)

Which init system for Debian?

Posted Nov 7, 2013 1:33 UTC (Thu) by Lukehasnoname (guest, #65152) [Link] (3 responses)

I don't get this:

>Upstart is covered by a copyright license agreement, which contributors must sign to have their contributions included upstream. This is an issue for many Debian developers, who are unwilling to sign such an agreement (usually because of the asymmetry of the agreement in question) and object to core packages being covered by such terms that they will not contribute under. The position of the Debian maintainers is that, while contributions to upstream must be covered by the CLA, no such considerations attach to the Debian package; if Debian ever decides that upstream maintenance is inadequate, we can always fork upstart, since the code itself is GPL and would be no worse off than we are today with a sysvinit package that also has no upstream.

So if I contribute to the project, I must give copyright to Canonical, but if I make an exact fork, merge all changes from upstream, then republish, I'm alright?

Sounds reasonable to me.

Which init system for Debian?

Posted Nov 7, 2013 2:23 UTC (Thu) by zuki (subscriber, #41808) [Link]

> Sounds reasonable
It works for small changes. But as soon as you implement something bigger, you pull changes from upstream, and have to resolve conflicts which pop up all over the place. This requires a lot of tedious manual work, *and* is very likely to lead to bugs, unless you know the codebase and understand upstream changes in detail. If you satisfy those requirements, then it's natural to want to fix things that you notice are wrong. But you can't.

So it's reasonable only if you limit yourself to small fixes here and there. Otherwise, it's just not worth the pain.

Which init system for Debian?

Posted Nov 7, 2013 14:33 UTC (Thu) by debacle (subscriber, #7114) [Link] (1 responses)

Yes, upstart is, like systemd, free software. You are not obliged to sign any agreement to change it. Canonical is free to use or not use the changes.

Which init system for Debian?

Posted Nov 8, 2013 17:12 UTC (Fri) by intgr (subscriber, #39733) [Link]

> You are not obliged to sign any agreement to change it.

It's not as simple as "don't sign the agreement". Debian developers have two choices with Upstart:
1. Expect developers to sign Canonical's copyright assignment agreement and contribute changes back upstream.
2. Fork Upstart and commit to maintain the fork forever, including patches contributed by the community.

Neither sounds like a good resolution.

Which init system for Debian?

Posted Nov 7, 2013 1:36 UTC (Thu) by Lukehasnoname (guest, #65152) [Link] (1 responses)

One more comment: The level of detail and intelligent discussion in the Debian pages on this is astounding. Friendly discussion, pros/cons, and rebuttals. Fantastic.

Which init system for Debian?

Posted Nov 7, 2013 12:02 UTC (Thu) by vonbrand (guest, #4458) [Link]

Don't worry. The flamewar is brewing as I type...

Which init system for Debian?

Posted Nov 10, 2013 19:10 UTC (Sun) by Jonno (guest, #49613) [Link] (6 responses)

>Since neither systemd nor upstart supports non-Linux kernels, adoption of either of those options would create some pain for the non-Linux projects. Of the two, upstart appears to be more open to adding non-Linux support than systemd, whose developers have gone on record as being opposed to code for portability.

I'm not a Debian Developer, just a user, but my take on the portability issue that it really shouldn't be an issue at all.

The whole point of providing both Linux and kFreeBSD ports is that they are *different*. One port is better for some use cases, the other port is better for other use cases. Railing against the Linux ports getting a better (eg different) init system than the kFreeBSD ports (or, for that matter, against the kFreeBSD ports getting better ZFS support than the Linux ports) are not only pointless, but even contra-productive to the whole raison d'être of having both Linux and kFreeBSD ports of Debian in the first place.

Or in other words: If they are not allowed to be different, why have both?

Which init system for Debian?

Posted Nov 10, 2013 19:41 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

And kFreeBSD is better for which use-cases?

Up until recently it was interesting because it could run ZFS. But now btrfs is pretty much competitive and by the time Debian+1 is released we can be sure that they'll be at feature parity.

Otherwise, it's hard to see FreeBSD's advantages.

Which init system for Debian?

Posted Nov 11, 2013 1:39 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (3 responses)

I use FreeBSD because of ezjail currently. I imagine once systemd-nspawn works on a distro that I don't have to touch every week (CentOS 7?), I'll probably swap to that.

Which init system for Debian?

Posted Nov 11, 2013 2:01 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, namespaces are quite nice already and have more functionality than ezjail. But yeah, they are a bitch to configure.

Which init system for Debian?

Posted Nov 12, 2013 23:22 UTC (Tue) by intgr (subscriber, #39733) [Link] (1 responses)

> on a distro that I don't have to touch every week (CentOS 7?)

So sounds like that's in fact *not* a use case for Debian/kFreeBSD. ;)

Which init system for Debian?

Posted Nov 12, 2013 23:27 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Currently, I use straight FreeBSD :) . I go in once every month or two to update ports in all the jails. Or when I see security notices go by...

Which init system for Debian?

Posted Nov 21, 2013 17:12 UTC (Thu) by nye (guest, #51576) [Link]

>Up until recently it was interesting because it could run ZFS. But now btrfs is pretty much competitive and by the time Debian+1 is released we can be sure that they'll be at feature parity.

The chance of btrfs being a serious competitor to zfs within the next 5 years is so close to zero as makes no practical difference. Calling them 'pretty much competitive' isn't even *remotely* accurate.

That said, you're right that this is no longer really an advantage of kFreeBSD, because zfsonlinux is very definitely a viable option these days.

Which init system for Debian?

Posted Nov 13, 2013 7:44 UTC (Wed) by glaesera (guest, #91429) [Link] (76 responses)

In my humble opinion it is perfectly OK to stick with Sys-V-init. It is in fact not the traditional sys-v-init anymore, but it evolved to a dependency-based approach some time ago.
If systemd is made the default init-system, then it really would be some kind of 'tail waggling the dog', if it happens only because of of GNOME.
Also please mind the development- and multiarch focus of Debian.
Systemd pobably works on the PC-architecture only and it surely works with the linux-kernel only, so that BSD- or hurd-variants also are disregarded.
It is also OK to make XFCE the default desktop in my opinion, because it requires no hardware-accelerated graphics, like GNOME does, so it works everywhere equally well.
Systemd is in Wheezy already and it should not be a problem to make GNOME depend on systemd in Jessie. After that, the GNOME-community really have to make up their minds, if they want to be PC-only and Linux-only, or want their environment to rule other systems also.

Which init system for Debian?

Posted Nov 13, 2013 9:06 UTC (Wed) by smurf (subscriber, #17840) [Link] (74 responses)

?? systemd runs on anything that's supported by a recent-enough Linux kernel. Not just "PC-only". Whatever gave you that idea?

Also, SysV-init's "dependency-based approach" is a half-baked pseudo solution. (a) it does not know when a service is up ("/etc/init.d/foo start has exitcode zero" is not at all the same thing), (b) systemd's socket activation means that you can forget about many dependencies as they simply do not matter any more, (c) socket activation also means that you can seamlessly restart a service, a feat which is impossible with Sys5-init.

I'm not going to rehash all the other neat features which are impossible (or very difficult) with SysV-init.

Init scripts are not going to go away any time soon, it's not as if SysV init suddenly vanishes from the face of the earth. But I'd rather have a full-featured init system which works well for the vast majority of Debian users. Why should 99.9% have to endure SysV's deficiencies, limited by the few kBSD people who can't run it?

Which init system for Debian?

Posted Nov 13, 2013 13:44 UTC (Wed) by hummassa (guest, #307) [Link] (11 responses)

> (a) it does not know when a service is up
> (b) systemd's socket activation means that you can forget about many dependencies as they simply do not matter any more
> (c) socket activation also means that you can seamlessly restart a service, a feat which is impossible with Sys5-

> I'm not going to rehash all the other neat features which are impossible (or very difficult) with SysV-init.

What no one else could explain to me, up to the present moment, is *why* do those things (which are neat, I agree) belong to the init process. Services infrastructure is great, but it does not need to be in init...

Which init system for Debian?

Posted Nov 13, 2013 14:20 UTC (Wed) by raven667 (guest, #5198) [Link]

Why wouldn't you put this function there? In the design of the UNIX system, init clearly has the responsibility for starting and restarting processes, handling zombies and managing the lifecycle of the system. Sure, SysV init really can only handle managing TTYs directly, because that is what was most important when it was designed, but it seems clear to me that this is how the system is supposed to work, and that the whole /etc/init.d system is just a hack layered on top to handle the additional complexity of services that init doesn't have the functionality to handle.

That problem is now resolved.

Which init system for Debian?

Posted Nov 13, 2013 14:20 UTC (Wed) by HelloWorld (guest, #56129) [Link] (5 responses)

Why does anybody make a fuss about having a slightly bigger init daemon when we have a kernel that is tens or hundreds of times as big?

Which init system for Debian?

Posted Dec 5, 2013 12:54 UTC (Thu) by malor (guest, #2973) [Link] (4 responses)

In my case, attack surface, mostly.

I would rather see truly separate programs to accomplish all the things that systemd is putting its tentacles into, because the chance of a system-compromising bug goes up at a rough square with the number of features on offer within the same binary. Every feature added to a program has a chance of interacting poorly with every other feature.

Putting things into separate binaries, with clearly defined, published interfaces, makes reasoning about and preventing security issues far, far easier.

And, from a security standpoint, the Linux kernel sucks, so there is an existing, very real reason to distrust the mega-feature approach to programming.

Which init system for Debian?

Posted Dec 5, 2013 13:29 UTC (Thu) by micka (subscriber, #38720) [Link]

Then there's no problem, because systemd is multiple separate binaries.

It's strange, I think this remark has already been done, with the same answer...

Which init system for Debian?

Posted Dec 5, 2013 13:30 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (2 responses)

Systemd *is* a lot of binaries. Check out the tab completion on `system<Tab>`. Even so, the tradeoff for lots of binaries is that now IPC is a problem if they're long running. If you get too many, now you have to validate the parsers of the IPC endpoints as well. At some point relying on the C compiler for checking arguments and such gets to be much easier there. The problem is usually in finding that line.

Which init system for Debian?

Posted Dec 5, 2013 17:24 UTC (Thu) by dlang (guest, #313) [Link] (1 responses)

systemd is a bunch of separate binaries, but instead of a well defined interface between them, the interface is whatever this version of systemd decides to make it, with the next version free to change everything.

Which init system for Debian?

Posted Dec 5, 2013 17:30 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Hmm? Systemd is pretty good about documenting their interfaces[1] and keeping backwards compatibility[2]. If you stray from the defined interfaces, then yeah, you might find some landmines. Which APIs are you referring to being in flux? Anything related to D-Bus[3]?

[1]http://www.freedesktop.org/wiki/Software/systemd/Interfac...
[2]http://upstream-tracker.org/versions/systemd.html
[3]http://www.freedesktop.org/wiki/Software/systemd/dbus/

Which init system for Debian?

Posted Nov 13, 2013 19:13 UTC (Wed) by smurf (subscriber, #17840) [Link] (3 responses)

You need *some* long-running "Job Manager" process which collects dependency information, manages control groups, decides what to start and stop and restart, and whatnot.(*)

PID 1 gets all the SIGCHLD notifications about dead processes. If it has to forward that information to the Job Manager, you get race conditions which are basically unfixable. Therefore init needs to be the Job Manager.

The question I like to ask whenever that comes up is "is there any advantage to moving this problem space to some other process?" So far I haven't seen any better reason than "init is supposed to be small" – which does not make sense because need the features anyway, so whether they're covered by one process or ten doesn't matter and consumes roughly the same amount of RAM.

(*) "need" in the sense of "I know that sysv-init doesn't have such a process, but it also doesn't have [ insert basically any systemd feature ], which I *want*, and which cannot reasonably be implemented without some management process, so …"

Which init system for Debian?

Posted Nov 15, 2013 18:59 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

PID 1 gets all the SIGCHLD notifications about dead processes.
Actually it gets a basically random subset: that from processes whose parents have died. (Of course, if the parents haven't died, they should be cleaning things up...)

It is clear, though, that this decision was originally made explicitly so that init could do exactly the sort of respawning and tidying up job that sysvinit is so manifestly bad at.

Which init system for Debian?

Posted Nov 15, 2013 20:52 UTC (Fri) by anselm (subscriber, #2796) [Link] (1 responses)

It is part of the initialisation protocol for Unix processes implementing background services to have themselves adopted by the init process just to make sure that the init process is notified when they exit.

That SysV init hasn't been doing anything with that information for the last 30 years or so is only too bad – but then again if you don't even know who your kids are in the first place, what are you going to do when they kick the bucket? Yay for systemd.

Which init system for Debian?

Posted Nov 15, 2013 23:50 UTC (Fri) by nix (subscriber, #2304) [Link]

... though, of course, if this information was actually useful systemd would be able to use it rather than cgroups.

What we really need is an option (inherited or systemwide, it doesn't matter) forcing *all* SIGCHLDs to go to PID 1, even if they also go to their real parent. But this is hard to implement in practice because the first thing you do on receipt of a SIGCHLD is reap the child, and you can't have two processes reaping the same child... not even a hack where PID 1's reap doesn't actually make the child go away if it has a live parent would work (the live parent could get to it first, leaving PID 1 with nothing to see).

Gah. Everything around child process management in Unix is just a horror. No wonder ptrace(), which builds on it in a halfwitted and agonizing fashion and has just the same problem with a process with 'two parents', is so horrible to use.

Which init system for Debian?

Posted Nov 14, 2013 12:51 UTC (Thu) by paulj (subscriber, #341) [Link] (61 responses)

Socket activation existed pre-systemd with SysV init, in things like inetd/xinetd, and other such daemons.

Which init system for Debian?

Posted Nov 14, 2013 13:53 UTC (Thu) by anselm (subscriber, #2796) [Link] (60 responses)

Not really. A daemon that is started through inetd or xnetd handles one request and then terminates again. Systemd's socket activation starts a service when the socket in question is accessed for the first time, but then the service keeps running and handles future requests without systemd having to re-activate it. With systemd, it makes sense to socket-activate a web server, which would be a very bad idea indeed with inetd/xinetd.

Which init system for Debian?

Posted Nov 14, 2013 16:38 UTC (Thu) by cortana (subscriber, #24596) [Link]

(For those wanting more information, look at the docs for Accept= in systemd.socket(5).

Which init system for Debian?

Posted Nov 14, 2013 16:46 UTC (Thu) by paulj (subscriber, #341) [Link] (58 responses)

That particular aspect of systemd requires the service to be modified to support that mode of operation, doesn't it?

That's a refinement of socket activation, but the basic principle of super-servers handling socket activation has long existed in Unix. The refinement you mention could be implemented with those too. The general idea of super-servers (socket activated or not) has also long existed, and seen a variety of uses. E.g. to manage terminals, etc.

Which init system for Debian?

Posted Nov 14, 2013 20:37 UTC (Thu) by anselm (subscriber, #2796) [Link] (56 responses)

That particular aspect of systemd requires the service to be modified to support that mode of operation, doesn't it?

Yes, much like a service must be modified to support inetd/xinetd style activation. Systemd can deal correctly with services written for inetd/xinetd, so on a systemd-based system these daemons are no longer required.

The refinement you mention could be implemented with those too.

Pigs could fly given sufficient thrust. Nobody claims that systemd invented socket activation. It's just that its implementation is considerably more powerful and flexible than that of inetd/xinetd. So far nobody has deigned to retro-fit systemd's socket activation features into inetd or xinetd, and the way things are going as far as systemd adoption is concerned, doing so may no longer be worth the trouble.

It may be worth looking at Lennart Poettering's blog entry on socket activation for more details.

Which init system for Debian?

Posted Nov 14, 2013 22:04 UTC (Thu) by raven667 (guest, #5198) [Link] (3 responses)

> Pigs could fly given sufficient thrust. Nobody claims that systemd invented socket activation. It's just that its implementation is considerably more powerful and flexible than that of inetd/xinetd. So far nobody has deigned to retro-fit systemd's socket activation features into inetd or xinetd, and the way things are going as far as systemd adoption is concerned, doing so may no longer be worth the trouble.

This is becoming a trend, everything that systemd does another program could do as well but while the systemd team is implementing, testing, stabilizing and deploying these and other features other software teams haven't even started talking about design yet which makes it seem unfair when comparing systemd to other init systems because they just don't do all of the things that the Linux kernel can do.

Which init system for Debian?

Posted Nov 14, 2013 22:17 UTC (Thu) by anselm (subscriber, #2796) [Link] (2 responses)

We must compare software systems based on the features that they actually have, not based on the features that they might conceivably have at some point in the future if some unspecified person eventually gets around to designing, implementing, and releasing them.

In that sense systemd is running rings around all the other init systems available today. It may »seem unfair« that systemd is so featureful and cohesive but that is not an accident at all – it is a result of the work that Lennart Poettering, Kay Sievers and their team did over a period of years. In the meantime those who are claiming that »SysV init could so do all of this, too!« have apparently been sitting on their hands. If it is really as easy as you say, then show us the code (and the documentation, examples, …)!

Which init system for Debian?

Posted Nov 14, 2013 22:34 UTC (Thu) by raven667 (guest, #5198) [Link] (1 responses)

I think we've either joined a mutual admiration society (where is my membership card?), or more likely I'm a bad communicator, because you are restating the point I thought I made just using different words.

Which init system for Debian?

Posted Nov 14, 2013 23:41 UTC (Thu) by anselm (subscriber, #2796) [Link]

Oh good. I wasn't quite sure :^)

Which init system for Debian?

Posted Nov 15, 2013 7:28 UTC (Fri) by paulj (subscriber, #341) [Link] (51 responses)

Actually, yes, the post I was replying to did seem to imply that socket activation was unique to systemd and impossible pre-systemd, when we had things like SysV-style init:

"socket activation also means that you can seamlessly restart a service, a feat which is impossible with Sys5-init."

This is just plainly incorrect, because Unix systems have had super-daemons doing seamless restarting with socket activation for donkey's years now.

I don't have anything against systemd, note. I am *not* arguing against it. However, this meme going that what it does is *only* possible with a kitchen-sink init and that it was impossible pre-systemd is simply wrong. Nothing prevented service management super-daemons being written, and they were. Indeed, if you look at *actual* SysV Unix systems like Unixware and AIX (IIRC), they had a few of them (IIRC - though I can't remember the details), to deal with various different aspects of the system. The basic SysV init took care of ensuring the super-daemons were always running (have we forgotten inittab?), and the super-daemons each managed their services in their own way.

Again, I'm not arguing against systemd, per se. However, an incorrect understanding of history helps no one.

Which init system for Debian?

Posted Nov 15, 2013 9:06 UTC (Fri) by khim (subscriber, #9252) [Link] (17 responses)

The whole thing is surreal. Lennart explains that some capability is impossible with sysV init and you explain that it's “plainly incorrect” because some other program (not SysV!) had this capability “for donkey's years now”? Some other program not available under Linux, mind you! What's wrong with you, people? Lennart never claimed that all the technologies which he introduced are all genuinely new (indeed, when he explains how they work he writes that it's easy to add them to CUPS because “it already supports launchd-style socket activation”!), he just claims they are new for Linux and are not available in SysV-init! Both facts are quite verifyable correct.

Yes, it's true that you can write “superdemons” with socket activation and couple these “superdemons” with Linux version of SysV init. But the fact is: noone did that in all these in all these “donkey's years”. Another fact is: noone did that after systemd introduction. Two these facts pretty much damn SysV init: either Linux version is not capable enough to warrant Unixware and AIX treatment or, alternatively, it does not have enough developers to keep it relevant. In both cases it's good idea to kill it and replace it with some alternative which does have developers and which is kept technocally competitive.

Ah, you don't like the fact that he only mentions predecessors in the second part, not upfront? But Lennart is not obligied to do that upfront: that's not a court case and not even a scientific article, that's post in Lennart's blog! He may write what he wants there and of course he will use the most positive description of “his baby”. Why not if the facts are correct?

Which init system for Debian?

Posted Nov 15, 2013 9:18 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link] (16 responses)

Actually he does mention both inetd and Apple launchd in the very first post about socket activation and he is very explicit about it. Noone claims that this idea is new at all. Just that systemd was the first to introduce it in Linux.

Which init system for Debian?

Posted Nov 15, 2013 14:14 UTC (Fri) by paulj (subscriber, #341) [Link] (15 responses)

I was responding to anselm, in the comments of this LWN article.

I've no strong opinion either way on systemd. Attempts to make it out as if my comment was in response to some article of Lennart's, which I never mentioned, are trying to straw-man me into some argument I've little care for. Indeed, the polarising nature of Systemd (or is it its developer?) and the fanatical style of debate the topic seems to draw out (either way) is all rather bizarre, I find. People should perhaps examine the level of civility they show.

FWIW, I had taken earlier comments talking about the impossibility of doing certain things under "SysV init" to mean "systems using SysV init", and continued in that vein. The only topic I have an interest in is the question of whether the same Systemd features are possible with a modular system under a SysV init, with functionality distributed over, less tightly-bound components. I think they are, as in my experience such systems have existed before. I disagree only with saying that it's impossible, and only possible with the monolithic Systemd way.

Again, I've no issues with Systemd, no more than with, say, the terminal management daemon in AIX or Unixware, or inetd or Solaris SMF or xinetd, etc. (OK, well, actually, I do have issues with SMF and its use of XML). Systemd seems to be managing services on my system, and the normal chkconfig and services tool interfaces seem to be working.

Note: This post is not generally directed at rahulsundaram.

Which init system for Debian?

Posted Nov 15, 2013 15:15 UTC (Fri) by anselm (subscriber, #2796) [Link]

The problem with SysV init is that SysV init, as such, doesn't actually do a whole lot at all. Most of what SysV init does, with respect to activating services, is encoded in service-specific (and distribution-specific) shell scripts. We all know that it is possible to make a shell script do pretty much anything. It is also clear that it is possible, in principle, to come up with various clever add-ons to SysV init that do interesting things with services like keeping them running and restarting them if they crash. The downside to this is that no two implementations of SysV init (the base init process plus the init scripts) are quite alike, and that therefore these add-ons, if they do exist, turn out to be fairly insular.

One of the big advantages of systemd in this context is that it tries to provide a single consistent and unified implementation of all the various bits and pieces that could in principle be built on top of SysV init, but which in most cases don't actually exist, and if they in fact do exist usually turn out to be highly system-dependent (or, in the case of Linux, distribution-dependent).

With systemd, we have a real chance of making Linux more consistent, better unified between different distributions, easier to understand, and more versatile. Claiming that most of what systemd does could also be implemented on top of SysV init, while very probably true, does not advance the discussion until the missing code has actually been designed, implemented, debugged, documented, and released under a free license (to fit all the various flavours of SysV init that are out there on various Linux distributions), and that is not likely to ever happen if one goes by the evidence of the last 30 years or so. Systemd, on the other hand, exists already (and is improving all the time), so the »SysV init can do this too« people have some serious catching up to do.

Finally, while we're at it, I can only recommend having a look at The Biggest Myths. The first myth that Lennart Poettering debunks in this article is »systemd is monolithic«.

Which init system for Debian?

Posted Nov 15, 2013 15:47 UTC (Fri) by khim (subscriber, #9252) [Link] (13 responses)

I was responding to anselm, in the comments of this LWN article.

Where LWN means “Linux Weekly News”.

I disagree only with saying that it's impossible, and only possible with the monolithic Systemd way.

How can you disagree with truth? Yes, it's impossible and it's only possible with the “monolithic systemd way”.

The only topic I have an interest in is the question of whether the same Systemd features are possible with a modular system under a SysV init, with functionality distributed over, less tightly-bound components. I think they are, as in my experience such systems have existed before.

Really. Ok. Let's discuss them, then. Note that systemd is not some huge monolythink binary: there are actually many specialized processes, but they all are developed together and are compiled as a large package. Which obviously means that “distributed over, less tightly-bound components” should include packages developed by separate teams and then bound together by packagers. This automatically excludes things like MacOS's launchd and Solaris' SMF (because, you know, they are tightly bound to the specific version of kernel, specific version of SysV init fork, etc). So… what we are discussing here? What “systems [that] have existed before” have you in mind, hmm…?

Yes, if you forget about “distributed over, less tightly-bound components” then you'll find quite a few such systems—but they don't exist under Linux today. Your AIX/MacOS/Solaris/Unixware packages are only interesting as a source of inspiration, they are not ported to Linux and it's not clear if they ever be proted (usually they are tied to some details of the appropriate systems which don't exist on Linux thus you can only use them as an inspiration, the code must be written from scratch or heavily modified). You may as well discuss design decisions of BeOS or Windows: they are just not relevant to discussion in question.

You can not simultaneously claim nothing prevented service management super-daemons [from] being written when it's perfectly cleat that they were not written. They were not written in twenty years of Linux history and they were not written in two years which passed after systemd introduction—which means that something is most definitely cause this phenomenon. “Simple to do” things are by definition… well… are simple to do and don't take years and/or decades! It may be technical problems or it may be lack of manpower, whatever. The fact still remains: they are not available today. If you want proper socket activation with seamless restarts, keep-alive capabilities and so on then systemd is the only game in town on Linux. There are other solutions developed for other OSes but they are tightly bound to these OSes and thus are not suitable for Linux distribution.

Which init system for Debian?

Posted Nov 15, 2013 19:03 UTC (Fri) by nix (subscriber, #2304) [Link] (9 responses)

You are apparently claiming that inetd, xinetd, et al do not exist, and that their functionality can only be implemented by something like systemd, as a direct response to comments pointing out that they do exist and are counterexamples to just that claim. Are you even reading the comments you're responding to?

Which init system for Debian?

Posted Nov 15, 2013 19:49 UTC (Fri) by anselm (subscriber, #2796) [Link] (8 responses)

inetd and xinetd do exist and they do indeed support a restricted type of socket activation. However, comparing what inetd and xinetd can do to what systemd does is like comparing a bicycle to a fighter jet. They do somewhat strain the notion of »counterexample«.

The other thing is that systemd does what it does with a unified UI that uses the same configuration file structure and command line syntax across all the types of service it supports. From a pragmatic point of view this is a big advantage compared to cobbled-together approaches like »SysV init with inetd/xinetd and loads of custom shell scripts all over«, because apart from its technical advances it makes the system easier to understand, teach, and learn.

On the other hand, the idea of putting layers upon layers of badly-designed stuff on top of SysV init in the name of »loosely coupled modularity« makes for a system that is missing exactly the sort of tight integration that systemd offers, while providing only a subset of the features. People who are new to Linux – and I'm speaking as somebody who teaches Linux system administration for a living – need to get used to various obtuse file formats and directory arrangements like /etc/inittab vs. /etc/inetd.conf (or for that matter /etc/xinetd.conf) vs. /etc/init.d vs. /etc/rc2.d and so on, with distribution-specific tools to do this and that and no attempt at anything like consistency within the system itself, let alone between the implementations that various distributions provide. And that is the great ideal that can do whatever we require and that we need to defend at all costs from newfangled abominations like systemd and Upstart? Please.

Which init system for Debian?

Posted Nov 15, 2013 23:51 UTC (Fri) by nix (subscriber, #2304) [Link] (5 responses)

Oh, I know all that. But the fact remains that superdaemons *do* exist, and khim's apparent claim that they don't and are impossible without systemd is simply and factually wrong. That it's also in direct response to a comment that points out the actual existence of just such superdaemons makes me wonder if I've misunderstood what khim was saying somehow -- but if I have, it seems so has everyone else who's responded.

Which init system for Debian?

Posted Nov 16, 2013 0:04 UTC (Sat) by khim (subscriber, #9252) [Link] (4 responses)

But the fact remains that superdaemons *do* exist, and khim's apparent claim that they don't and are impossible without systemd is simply and factually wrong.

Citation needed. Badly. You claim that inetd and xinetd can seamlessly restart a service. Ok. I want to configure service in a mode where it's started when first client is calling it and is transparently restarted after crash (without dropping connections, of course). Nothing fancy, just basic requests which were implementable in Windows NT 3.1 twenty years ago. How to do that with xinetd?

Which init system for Debian?

Posted Nov 16, 2013 0:45 UTC (Sat) by anselm (subscriber, #2796) [Link] (3 responses)

That is not the business xinetd is in, so it's no big surprise that it can't do it (anymore than it can shine shoes and make coffee).

The problem seems to be that there appear to be several definitions around of what »socket activation« actually means. Inetd/xinetd listen to a socket, and if a connection request comes in they start the daemon in question, which handles the request and then quits. The next connection request causes another instance of the daemon to be started. This of course is terribly inefficient for the kind of service such as HTTP that is not based on long-running sessions, and not especially efficient for services that are, like FTP or SMTP.

Systemd can do this, too, but it also supports a different kind of socket activation where the first connection request causes the daemon to be launched, and then instead of quitting after the request has been handled, the daemon just keeps running to handle any further requests (with no more overhead for extra startups). This is very convenient but inetd/xinetd simply don't do it. Possibly nix knows about some tool based on SysV init that can do that sort of thing, but if it does exist it is certainly not anywhere near mainstream on Linux.

Which init system for Debian?

Posted Nov 16, 2013 6:44 UTC (Sat) by spaetz (guest, #32870) [Link]

anselm, xinetd can indeed start a service on first demand AND keep it running for allsubsequent requests. Check out Lennart's post if you don't believe me :-) .

xinetd might be a bicycle, but it does have electric motor and 21 gears...

Which init system for Debian?

Posted Nov 16, 2013 17:57 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

*Sigh* There are two way to "socket-activate" a process.

All start by actually opening a socket and listen()ing to it. When a connection request arrives,

(a) accept the connection, start a new server, hand the new connection to it on stdin/out. This is, in general, not a good idea because you pay the startup cost for every request.

(b) DO NOT accept the connection; instead, start a new server, hand the listening socket to the server (typically on stdin). Ignore the socket until the server dies. (x)inetd, systemd, upstart, … all can do this.

The condition "the server dies" obviously does not work if the daemon forks-and-exits for whatever reason. xinetd also does not work for you if a server wants to listen to multiple sockets, or (these days) should start when an udev request arrives for it … or maybe you want to manually start the thing because you know you'll need it in a few minutes …

… and shutting it down cleanly has its own grab bag of problems, which (x)inetd does not address AT ALL.

I mean, come on. You can find some piece of code which does a half-assed job of (almost) anything systemd can do . What nobody in this whole discussion has ever mentioned is a program which today improves on anything that systemd can do.

Which init system for Debian?

Posted Dec 8, 2013 16:24 UTC (Sun) by nix (subscriber, #2304) [Link]

Quite. Which is why, violently conflicted though I am on systemd and concerned though I am about its relentless scope creep and apparent desire to take the entire core of the system and wrap it up in a single package (eep -- only, well, glibc and the kernel do that already and nothing bad happened), I'll probably eventually end up using it on systems other than VMs. It does, after all, work, and work well: better than all the competition. It's just a scope-creepy monster at the same time.

Which init system for Debian?

Posted Nov 16, 2013 9:42 UTC (Sat) by paulj (subscriber, #341) [Link] (1 responses)

There was no shell hairball of init scripts needed with the super-daemon approach. The super-daemon could be launched and *managed* directly by init (inittab), and the super-daemon monitored things (sockets, ttys, etc) and launched services on demand (which could well go on to handle multiple requests, see, e.g., the wait option in inetd/xinetd).

The shell SysV init scripts were indeed a hairball and problematic and racy wrt start. I'm not saying anything to the contrary on that.

All I'm saying is that daemons to monitor resources, launch service handling child processes on demand, and manage their lifetimes (respawning, etc), have a long tradition already in Unix. I'm still curious what it is that can be done in PID 1 wrt child management that is impossible in the more distributed fashion? (And be careful not to conflate what was added to the process management capabilities by cgroups, and used to good effect by systemd, with functionality that is uniquely implementable in PID 1).

(Ob monolithic - Systemd apparently is modular only at compile time, not quite the modular/monolithic distinction I had in mind in my earlier comment).

Which init system for Debian?

Posted Nov 16, 2013 14:27 UTC (Sat) by raven667 (guest, #5198) [Link]

> (Ob monolithic - Systemd apparently is modular only at compile time, not quite the modular/monolithic distinction I had in mind in my earlier comment).

Well everything related to starting and stopping processes using all of the features the Linux kernel provides is in PID 1 but there are other ancillary daemons like udevd, journald, logind and utilities that do various jobs during system startup in /usr/lib/systemd, essentially C programs which replace the system setup logic that all the shell scripts used to do (setting the hostname, mounting filesystems with optional fsck, etc.)

Which init system for Debian?

Posted Nov 20, 2013 4:10 UTC (Wed) by ThinkRob (guest, #64513) [Link] (2 responses)

launchd isn't as tightly bound as you think. It's been ported to other OSs, although I don't think it's used outside of Mac OS X.

Which init system for Debian?

Posted Nov 20, 2013 4:43 UTC (Wed) by raven667 (guest, #5198) [Link] (1 responses)

Has it been ported to non-BSD kernels?

Which init system for Debian?

Posted Nov 21, 2013 0:53 UTC (Thu) by ThinkRob (guest, #64513) [Link]

It was ported to FreeBSD at least twice AFAIK.

So that makes two different kernels (XNU and FreeBSD) that it's run under. (I know XNU uses FreeBSD code in its kernel, but it's still a pretty different beast.)

Which init system for Debian?

Posted Nov 15, 2013 17:26 UTC (Fri) by smurf (subscriber, #17840) [Link] (32 responses)

> the super-daemons each managed their services in their own way

… which did not work particularly well then, and it does so even less now.

You CANNOT reliably (no race conditions, no possibility for strange unexpected stuff in the environment, …) control a service under Unix/Linux/whatever unless you _are_ PID 1 or, at the very least, integrate with init so tightly that using a separate process does not make much sense.

This is a basic fact of Unix/Linux system architecture.

Another problem with these super daemons was (and is) that nobody likes to use them, because they profess to solve one particular problem and leave everything else to … whatever.

systemd tries to solve all problems you're ever likely to encounter when managing your daemons and related jobs (and IMHO mostly successfully, too, but I've written *that* often enough lately).

Which init system for Debian?

Posted Nov 15, 2013 22:28 UTC (Fri) by paulj (subscriber, #341) [Link] (31 responses)

What are the race conditions exactly?

Which init system for Debian?

Posted Nov 16, 2013 17:30 UTC (Sat) by smurf (subscriber, #17840) [Link] (30 responses)

Simple example: you want to stop a service. This involves (a) scanning /proc, reading its PID file, or whatever; and (b) killing a specific PID.

Between A and B, however, anything could happen. In particular, the service could have died by itself and something else could have reused its PID. Which is then killed off randomly. Ouch.

This is somewhat fixable if the service is a direct child of PID 1 (by asking init nicely to please kill that specific process -- if you include additional information like e.g. the time it was started). If there's a random service manager in between, you need to talk to that process instead. Assuming that the daemon in question didn't fork. :-/

I can probably think of a couple more races. Or you might ask Lennart – he has probably more to say about this. ;-)

The bottom line is, yes this is all somewhat fixable if you spend enough effort on it, but other than the systemd people _nobody_has_.
(Upstart does not know which processes have been forked off by the daemon in question, and thus cannot always shut down a specific service cleanly. systemd uses cgroups to keep track of that information.)

Which init system for Debian?

Posted Nov 16, 2013 18:28 UTC (Sat) by paulj (subscriber, #341) [Link] (3 responses)

You're describing the race intrinsic to the shell SysV rc/init scripts, I think. We're agreed using shell scripts to start daemons and kill them can be racy.

However, a super-daemon knows the services it manages, knows the processes it has launched and knows their PIDs. All you do is change the configuration and hey presto. E.g., edit inetd.conf or xinetd.d/$SERVICE and HUP the super-daemon, hey presto. Edit inittab and tell init to reload, etc. Again, other Unixes (SysV ones particularly - AIX had quite a few super-daemon service management things, IVR) took this approach with some success.

It was also quite possible, with the previous, simple Linux init to have it run stuff from inittab. Just run the daemon in the foreground.

The claims that *only* the Systemd kitchen-sink-PID-1 service manager can work reliably still seem unfounded to me.

NB: Claims that the Systemd monolithic way is more unified and more manageable are another thing. That may be the case, but I don't have a strong opinion there. Systemd may well also be a huge improvement on the SysV shell initscripts. I'd appreciate it though if people don't try to put words in my mouth as if I'm arguing otherwise, thanks. :)

Which init system for Debian?

Posted Nov 16, 2013 18:32 UTC (Sat) by paulj (subscriber, #341) [Link]

Err, "run the daemon in the foreground", many "daemons" have an option to not daemonise for such reasons (and all /should/). Indeed, many default to not doing so and actually require an option to be given to daemonise. :)

Which init system for Debian?

Posted Nov 16, 2013 19:45 UTC (Sat) by smurf (subscriber, #17840) [Link]

>> You're describing the race intrinsic to the shell SysV rc/init scripts

Where did I say that?

The race condition doesn't go away just by rewriting the code in C or whatever.

>> a super-daemon knows the services it manages, knows the processes
>> it has launched and knows their PIDs.

It does not know what else these processes forked off, and thus it cannot clean up after them. Don't ask me how often I had to do that manually, for some Apache-FCGI subprocess that got stuck in la-la-land.

Which init system for Debian?

Posted Nov 19, 2013 1:18 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

I have a perennial problem with daemons starting several acceptor processes. That do NOT quit once the parent dies (for example, Flask webserver).

Systemd solves this nicely by simply slaughtering anything within the service's cgroup.

Which init system for Debian?

Posted Nov 16, 2013 19:50 UTC (Sat) by HelloWorld (guest, #56129) [Link] (3 responses)

Well, one could argue that the right way to fix this is to make PIDs 64-bit, so that they never have to be reused. Of course doing this without breaking binary compatibility would be non-trivial.

Which init system for Debian?

Posted Dec 8, 2013 16:27 UTC (Sun) by nix (subscriber, #2304) [Link] (2 responses)

Doing this without irritating everyone who had to type in or read PIDs would be even more non-trivial!

Imagine, over a noisy phone line:

"What PID is that?"
"41921160436"
"*sigh*"

(well, OK, that machine has been forking up a storm for implausibly long. But still. :) )

Which init system for Debian?

Posted Dec 8, 2013 17:25 UTC (Sun) by andresfreund (subscriber, #69562) [Link]

Isn't the actual limit in linux ~2^22? ;)

Which init system for Debian?

Posted Dec 8, 2013 19:18 UTC (Sun) by smurf (subscriber, #17840) [Link]

$ echo 41921160436 >/tmp/annoying_process

… though the main reason against increasing the PID space that much is the ps output's legibility – and human limitations: present-day PIDs 14127 and 14217 are too similar already, so how would you distinguish between 41921160436 and 41921106436?

Which init system for Debian?

Posted Nov 17, 2013 19:21 UTC (Sun) by luto (subscriber, #39314) [Link] (21 responses)

This can be done racelessly on Linux using PR_SET_CHILD_SUBREAPER. An init-like program (it doesn't even have to be PID 1) can create a dedicated child per service. That child calls PR_SET_CHILD_SUBREAPER and then forks and starts the service. To kill the service, the child iterates its children and kills them, in a loop, until the service is gone.

It's ugly, it's prone to failure if the service fork-bombs, and it's a bit overcomplicated. That being said, I think it can and should be improved to make it work well.

IMO using control groups for service management is an abomination and should go away. It's a case of using a sledgehammer to drive in a thumbtack, and, even worse, the world is moving in the direction of having only one sledgehammer available. All Unixes have a a process tree -- let's *fix* it and *use* it.

(At work, I use a little Python script to manage services. About twenty lines of code gives me a completely functional way to Ctrl-C the service manager and clean everything up. No privilege required.)

Which init system for Debian?

Posted Nov 17, 2013 20:13 UTC (Sun) by raven667 (guest, #5198) [Link] (20 responses)

Re: PR_SET_CHILD_SUBREAPER
> It's ugly, it's prone to failure if the service fork-bombs, and it's a bit overcomplicated.

Re: Control Groups
> It's a case of using a sledgehammer to drive in a thumbtack

There is no extra points for being clever and making a system work that is complicated and prone to failure, using the proverbial sledgehammer to drive the thumbtack is often the correct engineering choice, simple and effective as opposed to high-tech is often a benefit for reliability.

Which init system for Debian?

Posted Nov 17, 2013 20:29 UTC (Sun) by luto (subscriber, #39314) [Link] (19 responses)

As far as I know, using control groups is subject to exactly the same failure: if children (i.e. processes in the control group) appear faster than you can kill them, then you'll never kill them all.

And making control groups a mandatory requirement for service management has all kinds of problems. The API is acknowledged to be utter crap (it's far worse than PR_SET_CHILD_SUBREAPER), it's far more complicated to use than PR_SET_CHILD_SUBREAPER, it's nonportable and will never be portable, it requires privilege, and it will soon prevent non-systemd uses of control groups.

Continuing the silly analogy, systemd's sledgehammer is not overkill, but it doesn't even work much better than a thumb.

Which init system for Debian?

Posted Nov 17, 2013 21:05 UTC (Sun) by raven667 (guest, #5198) [Link] (18 responses)

> As far as I know, using control groups is subject to exactly the same failure: if children (i.e. processes in the control group) appear faster than you can kill them, then you'll never kill them all.

I don't believe this is the case, the kernel sends the signal to all processes in the group, they don't have the option of continuing to run and call fork(). http://0pointer.de/blog/projects/systemd-for-admins-4.html

Re: Linux Control Groups
> it's nonportable and will never be portable

This is an implementation detail on Linux that is different on every kernel and is not part of the application interface. Only programs which need to deal with the underlying kernel plumbing will care and those are almost by definition different for each OS kernel.

Which init system for Debian?

Posted Nov 18, 2013 4:54 UTC (Mon) by dlang (guest, #313) [Link] (17 responses)

sending signals is not atomic, so between the time that you send signals to the processes, and the time they process the signal, they could have called fork and the child was not sent a signal.

Which init system for Debian?

Posted Nov 18, 2013 5:36 UTC (Mon) by luto (subscriber, #39314) [Link] (16 responses)

Indeed.

I'd argue that a really good implementation of signal-a-whole-subtree would guarantee that everything gets killed.

I want a set of new kernel features that are actually designed for process subtree management. I'm not sure what the best way to name a subtree is (the pid that started it? -- this has issues if that pid dies (even by OOM) and gets reaped. an fd? -- more complicated.) Aside from the naming issue, I think that the only new operations needed are:

  • Signal the whole subtree. Maybe even just SIGKILLing the whole subtree is enough.
  • If you're managing a whole bunch of subtrees, a good way to translate from a pid to the subtree that contains that pid could be helpful.
Enumerating processes in the subtree is already possible with /proc/PID/task/TID/children (currently hidden in CONFIG_CHECKPOINT_RESTORE).

I think that this could be a lot simpler than cgroups.

It would be great if something like this were added to Linux and to *BSD: maybe the systemd people would then consider supporting other operating systems. I don't know of anything other than cgroups that systemd needs that's Linux-specific.

Implementing this should be straightforward, especially if you're willing to accept the kill operation missing things that fork while killing. I think that the only tricky part would be figuring out how to keep track of multiple subtrees per service manager cleanly (and convincing the systemd developers to use it).

Which init system for Debian?

Posted Nov 18, 2013 5:46 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

how would a 'signal the entire subtree' that was still racy with processes forking be any better than what we have today?

Which init system for Debian?

Posted Nov 18, 2013 6:04 UTC (Mon) by luto (subscriber, #39314) [Link]

That part wouldn't (but you can still call the kill function in a loop).

The benefit is that this would be simple, wouldn't require privilege, and wouldn't require that the One True Cgroup Hierarchy (TM) actually matched the systemd hierarchy. (I have a production system with a cgroup hierarchy that does not match the hierarchy that systemd would come up with. I could probably come up with a mostly equivalent hierarchy that would match, but I don't think that I should need to.)

(You can currently get a working unprivileged service manager because systemd creates /sys/fs/cgroup/systemd/user/UID.user owned by UID. This seems like a suboptimal solution.)

Which init system for Debian?

Posted Nov 18, 2013 12:55 UTC (Mon) by HelloWorld (guest, #56129) [Link] (12 responses)

> I don't know of anything other than cgroups that systemd needs that's Linux-specific.
Systemd also uses inotify and epoll and netlink and literally dozens of other things. A port of systemd to anything other than Linux is simply never going to happen.

Which init system for Debian?

Posted Nov 20, 2013 15:34 UTC (Wed) by foom (subscriber, #14868) [Link] (11 responses)

inotify, epoll -> kqueue. netlink -> ioctl, usually (not sure exactly what systemd uses it for).

Certainly, you can find a much longer list of linux-specific APIs at Myth #15 on http://0pointer.de/blog/projects/the-biggest-myths.html

However, I do think if you wanted to make a systemd-lite, concentrating only on normal server usage, you could make it work, IF there was a way to watch process trees equivalent to what cgroups gives you.

I mean, when porting it, you can explicitly NOT try to handle a bunch of the other useful features it implements (which, for example, make system startup reliable in the presence of dynamic devices, by allowing mountpoint dependencies). Cut that out, support for network changes, filesystem namespaces, etcetc.

The portability layer would still be annoying, and such a systemd-lite would probably have to be a fork (ala portable openssh), but, I think, entirely feasible.

Which init system for Debian?

Posted Nov 20, 2013 22:43 UTC (Wed) by HelloWorld (guest, #56129) [Link] (10 responses)

> I mean, when porting it, you can explicitly NOT try to handle a bunch of the other useful features it implements (which, for example, make system startup reliable in the presence of dynamic devices, by allowing mountpoint dependencies). Cut that out, support for network changes, filesystem namespaces, etcetc.
If you remove 90% of the functionality of the project, and implement the remaining 10% in another way, then it's not a port. It's a different program sharing a part of the code base.

Which init system for Debian?

Posted Nov 20, 2013 23:08 UTC (Wed) by luto (subscriber, #39314) [Link] (9 responses)

I can't shake the feeling that this is an odd form of FUD from the systemd people.

At its core, systemd is a service and dependency manager. It supports lots and lots of directives in unit files, most of which could easily be optional. It also supports a bunch of magic to mount things and boot up a Linux system.

I fail to understand what Linux-specific features are needed for the core functionality of acting as PID 1 (e.g. reaping things and setting up controlling ttys) and monitoring services, other than being able to watch subtrees and having something like inotify or fanotify to keep track of configuration.

Here's the list from the systemd myths page:

cgroups, fanotify, umount2(), /proc/self/mountinfo (including notification), /dev/swaps (same), udev, netlink, the structure of /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces of all kinds, various prctl()s, numerous ioctls, the mount() system call and its semantics, selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, ...

cgroups: only really needed to watch subtrees.

fanotify, inotify: presumably for watching the configuration directory. I think that all relevant OSes can do this.

mountinfo: only needed if you want mounts.

udev, netlink, /sys: irrelevant -- could easily be turned off (e.g. for systemd --user).

/proc/$PID/whatever: either only needed for logind stuff (which is optional) or (I assume) for diagnostics.

capabilities, namespaces, prctl, selinux, audit: completely irrelevant (again, see systemd --user and/or don't use those features. In any case, systemd clearly does not depend on selinux.)

/dev/input: you're kidding, right? maybe this is needed for logind.

SCM_RIGHTS: not Linux-specific. (and I'm pretty sure that something like SCM_CREDENTIALS is widely supported as well.)

This is getting boring. Given that systemd --user *works*, it seems like it should be relatively easy to configure out most of systemd and to put some kind of portability wrapper around the rest. The main stumbling block seems to be that the systemd people don't want to talk about it.

Which init system for Debian?

Posted Nov 20, 2013 23:57 UTC (Wed) by rodgerd (guest, #58896) [Link] (7 responses)

> The main stumbling block seems to be that the systemd people don't want to talk about it.

The main stumbling block seems to be a lot of people insisting it's possible to create a version of systemd which is portable, or provide all of systemd's functionality with a completely different design, *without any of those people having produced any working code to back up that assertion*.

Which init system for Debian?

Posted Nov 21, 2013 5:35 UTC (Thu) by luto (subscriber, #39314) [Link] (5 responses)

Sorry to snipe, but I'm sure not going to write that code when the systemd people have said over and over that, even if it were possible to cleanly do such a thing, they wouldn't want it.

My point here is that what systemd is doing with cgroups is ugly and will, once single-hierarchy rules go into effect, suck for a decently large group of users. The kernel could provide a better facility, and everyone (including, most likely, systemd's code complexity) would win if systemd started using it. As a side benefit, if the API were nice, maybe other OSes could adopt it.

Which init system for Debian?

Posted Nov 21, 2013 6:10 UTC (Thu) by raven667 (guest, #5198) [Link] (2 responses)

It would make more sense to extend launchd or fork systemd and rewrite the internals for a different OS kernel, maintaining that as a separate project, than to try and add the complexity to systemd of trying to make the internals modular across different OS kernels. I think that's an honest and reasonable technical position to take, presuming an API level of the underlying components (Linux kernel version blah) makes for much simpler programming than if you have to test and fall back for every possible feature incompatibility.

Which init system for Debian?

Posted Nov 21, 2013 9:51 UTC (Thu) by khim (subscriber, #9252) [Link] (1 responses)

Systemd internals are already quite modular and there are many small functions which can be used as points where you may add portbility glue. It's different kind of decision: it's not that Linux offers easier programming model, it's the fact that Linux offers fixed programming model. You don't need to debate how certain function functionality like crypttab or ConditionPathIsMountPoint should be implemnted under different OSes or, more importantly, even if it can be implemented under different OSes! If something is seriously lacking in Linux kernel then it can be added to Linux kernel, after all…

Which init system for Debian?

Posted Nov 21, 2013 13:06 UTC (Thu) by hummassa (guest, #307) [Link]

are you arguing that Debian kFreeBSD/HURD/etc should just implement the needed linuxisms (cgroups,etc) in kFreeBSD/HURD/etc? 'cause it actually looks like a nice idea, if anyone should be up to it...

Which init system for Debian?

Posted Nov 21, 2013 19:26 UTC (Thu) by smurf (subscriber, #17840) [Link]

They don't want *BSD and Hurd compatibility code in their source base because it'd be very intrusive in a lot of places. They would have no way to test it and no way to fix it if they should inadvertently break it.

That looks like a perfectly reasonable decision to me, and looking at that list of Linux idioms in systemd I agree that it'd make more sense to fork the thing.
Assuming that anybody actually wants to do the work, which frankly I doubt – it'd be quite substantial.

Which init system for Debian?

Posted Nov 21, 2013 21:01 UTC (Thu) by intgr (subscriber, #39733) [Link]

> I'm sure not going to write that code when the systemd people have said over and over that, even if it were possible to cleanly do such a thing, they wouldn't want it.

No, you got it backwards. They're saying that:
1. Such a port would not be clean.
2. BSD developers wouldn't be interested in adopting systemd anyway.

And because of these 2 reasons, they don't consider any porting effort to be worthwhile to merge/maintain. It would be quite silly to maintain a whole FreeBSD port for the Debian/kFreeBSD people alone.

The goal of systemd has from the start been to unify many of the distro-specific bits, and to be adopted by default across Linux distros. They consider that very unlikely to happen in the BSD world -- that they would adopt a critical core component that's licensed under GPL and led by Linux overlords.

But they are reasonable people. If you could demonstrate them being wrong on both counts, I'm sure they would reconsider. Even if, as you imply, (1) is doable then I would be extremely suspicious about (2).

Which init system for Debian?

Posted Nov 22, 2013 3:56 UTC (Fri) by foom (subscriber, #14868) [Link]

Yes. The fundamental problem is that nobody actually *cares* about having systemd running on FreeBSD, except in that some people seem to see having systemd run on the FreeBSD kernel as a blocker for adopting it on Debian/Linux.

I briefly considered Just Porting It myself, so that the stupid argument about portability could stop, but then I realized: 1) I don't have FreeBSD installed anywhere, and have never run a FreeBSD system, 2) I don't really want to learn how to run/administer FreeBSD, 3) even if I managed to get it to work, I might then get stuck *maintaining* the port which would really suck, and 4) Wait, this whole thing is stupid, I really *really* don't care about FreeBSD -- especially not Debian/kFreeBSD, which almost literally nobody uses. Why was I even considering wasting time on doing something nobody, not even me, actually wants?

Which init system for Debian?

Posted Nov 22, 2013 11:06 UTC (Fri) by jezuch (subscriber, #52988) [Link]

> I fail to understand what Linux-specific features are needed for the core functionality of acting as PID 1

Nothing's "needed". They use these features because they're there, they're useful and there's no point in not using them (except portability, which was commented upon by others).

Which init system for Debian?

Posted Nov 18, 2013 15:18 UTC (Mon) by raven667 (guest, #5198) [Link]

> I'd argue that a really good implementation of signal-a-whole-subtree would guarantee that everything gets killed.

Isn't that the feature Linux Control Groups offers? If you call SIGKILL on a Control Group, I don't think that the processes in that group get a chance to run from the scheduler to be able to call fork() so they are reliably dead. Anything that involves looping over a list in userspace is inherently racy and will fail from a design perspective, that's why using Control Groups and other kernel features is so key to the design of systemd.

I don't think cgroups themselves are terribly complicated, the rate limiters and controllers are complicated but cgroups themselves are simple. I think that is part of the reason why the kernel team is looking to rewrite them, they are _too_ simple and expose too much internal implementation detail.

Which init system for Debian?

Posted Nov 15, 2013 6:45 UTC (Fri) by smurf (subscriber, #17840) [Link]

>> That particular aspect of systemd requires the service to be modified
>> to support that mode of operation, doesn't it?

Yes. But the same thing holds for inetd -- the service in question needs to know how to handle the fact that its socket is on /dev/stdin.

In any case, inetd's socket thing does not support seamless server restarts, does not support multiple sockets, does not support dbus activation, and neither does it support starting the server on multiple conditions (not events!) (socket- and non-socket based).

The first three limitations also hold for upstart.

Which init system for Debian?

Posted Nov 13, 2013 14:22 UTC (Wed) by raven667 (guest, #5198) [Link]

This isn't being driven by GNOME, systemd is being discussed because of its technical merits first, so the rest of commentary depending on that kind of falls apart.

Which init system for Debian?

Posted Nov 17, 2013 14:03 UTC (Sun) by hadrons123 (guest, #72126) [Link] (1 responses)

The news for now is there is no init anymore in Debian.

Its like matrix: "There is no spoon."

http://www.joachim-breitner.de/blog/archives/627-Breaking...

Which init system for Debian?

Posted Dec 8, 2013 16:35 UTC (Sun) by nix (subscriber, #2304) [Link]

It's less insane than it sounds. The Lisp Machine basically worked that way: you used what would now be called suspend/resume and never ever shut it down unless an OS upgrade came along and forced you to. (Good thing too, 'cos booting took forever.)

Who cares?

Posted Dec 17, 2013 17:55 UTC (Tue) by flohoff (guest, #32900) [Link] (3 responses)

If we had discussed this 10 years ago i'd be interested. Today? Who boots anyway? Last boot is probably a year ago. So boot times as a non issue. Event based booting? I dont get the point whats been missing here.

I am a Linux oldtimer and i am in strong oposition of systemd. Its name speaks for itself - it sees itself to be the only attachment point for userspace. Dont have any gods besided me - I'll take care about consoles, booting, network sockets, dbus, udev and whatever it takes to make you feel comfortable.

For >20 years i have been thinking about pid 1 to be a minimalistic as possible reaper which takes care userspaces gets to life. Not a single line more.

When i read about the necessity for networking deamons to gain systemd event support by getting a fd passing interface I'd like to vomit all over the place. Some deamon claiming ports it does not speak the protocol of - Wait what?!? If a daemon is not started its a philosophy to tell others by sending a port unreachable not by faking some activity. It should not be called systemd but mimikrid.

Gnome3? Not interested - drop it - Worst thing in 2013 which came over me.

Who cares?

Posted Dec 17, 2013 18:23 UTC (Tue) by mpr22 (subscriber, #60784) [Link]

Who boots anyway? Last boot is probably a year ago.

Various people boot their computers rather more frequently than you for various reasons, including "so that I know it still boots", "so that I am not running a twelve-month-old kernel with widely-known vulnerabilities that have since been fixed", "because I have a dual-boot desktop system", and "because however much work has been done on it, I still don't entirely trust hibernation to come back up cleanly".

Some deamon claiming ports it does not speak the protocol of - Wait what?!?

A daemon setting up a socket it doesn't speak the protocol of, so that it can (when a connection attempt is made) fork(), exec() the daemon that does speak the protocol, and hand the socket to it, is not a Lennartism, or even a Linuxism; inetd was released as part of 4.3BSD in 1986.

Who cares?

Posted Dec 17, 2013 18:26 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Well then…

> Last boot is probably a year ago.

How are those security updates working for you then? Do you have any Internet-facing machines like this?

> I'll take care about consoles, booting, network sockets, dbus, udev and whatever it takes to make you feel comfortable.

Yeah…I like getting work done. About all I do is disable TTY 3-6 (removing some symlinks; sysvinit had me editing /etc/sysconfig/...something and I don't think even *this* is needed anymore (what with dynamic getty spawning)) by default and then I'm off setting up my user data. Much simpler.

> For >20 years i have been thinking about pid 1 to be a minimalistic as possible reaper which takes care userspaces gets to life. Not a single line more.

Then what about other systems that have adopted a more-than-minimal approach to PID 1? It's not like systemd is the first of its kind (though it certainly seems more comprehensive and well thought out).

> Some deamon claiming ports it does not speak the protocol of - Wait what?!?

Systemd doesn't talk over those ports; it just listens then starts the daemon when it needs to for it to call accept on the socket. It won't call listen if you don't have the service enabled, so systemd isn't just grabbing random ports. Also, have an interrobang: '‽' :) .

> Gnome3

I won't disagree too much about its usability, but dropping it probably isn't in the best interest of Linux (that's quite a few users you'd be abandoning) and who are you to say their opinions are wrong? Personally, I just use XMonad and tmux and ignore the whole shebang (though I do try to track freedesktop.org standards where I can).

Who cares?

Posted Dec 17, 2013 21:14 UTC (Tue) by raven667 (guest, #5198) [Link]

>I am a Linux oldtimer and i am in strong oposition of systemd. Its name speaks for itself - it sees itself to be the only attachment point for userspace. Dont have any gods besided me - I'll take care about consoles, booting, network sockets, dbus, udev and whatever it takes to make you feel comfortable.

I'm certainly more comfortable in a well-organized system where services are easy and reliable to start/stop/restart, logging is reliable and includes stdout/stderr from daemons, where creating a new service which may or may not know how to "daemonize" itself is easy and doesn't inherit from or pollute the login session I'm working from. Writing good systemd unit config files is much more straightforward and reliable than the piles of (distribution/platform specific) shell required for SysV init

The Linux kernel is now largely event driven/hotplug when it comes to devices which is why udev and NetworkManager need to exist, to handle and DTRT when those events are emitted. systemd services can have dependancies on devices, for example on the network being up or on a particular filesystem being mounted, or services which start when a particular USB device is inserted, which is why it needs to be aware of the hardware state and is a client of the device manager.

These features and requirements exist in Linux whether you like systemd or not. I don't think there is a benefit in pretending that Linux is a 20+ year old UNIX and refusing to handle the reality of the modern system. Even UNIX doesn't work that way anymore as the other major systems have switched away from SysV init already (Solaris/SMF, MacOSX/launchd for example)

Which init system for Debian?

Posted Feb 4, 2014 12:01 UTC (Tue) by djzort (guest, #57189) [Link] (9 responses)

Exim is an excellent MTA, the above comments amount to slander. The cult like devotion around postfix is unjustified.

Which init system for Debian?

Posted Feb 4, 2014 16:11 UTC (Tue) by foom (subscriber, #14868) [Link] (8 responses)

I didn't read it as saying anything bad about exim -- just that it's less popular. And that Debian isn't afraid to do something that is different than others if it makes sense.

I do see how it being compared with upstart might make one think it was being insulted, though...

Which init system for Debian?

Posted Feb 4, 2014 23:34 UTC (Tue) by anselm (subscriber, #2796) [Link] (7 responses)

And that Debian isn't afraid to do something that is different than others if it makes sense.

Debian picked Exim as the default MTA before Postfix was ready for prime time, and then never bothered to change again. After all, Exim is perfectly adequate for many applications, and it is trivial to replace it with Postfix (or indeed some other MTA such as Sendmail, qmail, or Courier, all of which are packaged for Debian) if that's desired,

It is fairly safe to say that had Postfix been usable at the time, Debian would have gone with it as the default MTA instead of Exim.

Which init system for Debian?

Posted Feb 5, 2014 1:32 UTC (Wed) by foom (subscriber, #14868) [Link] (6 responses)

Exim seems superior to postfix in most ways, despite postfix being more popular.

I know others disagree, but how is the decision *obviously* postfix, even today?

Which init system for Debian?

Posted Feb 5, 2014 22:16 UTC (Wed) by smurf (subscriber, #17840) [Link] (5 responses)

It's not. You can easily run a large email site with Exim.

Anyway, this comparison is moot. Both deliver email quite well, that's all they do and that's all they're supposed to do. Thus, this is not at all related to the systemd vs. upstart debate.

Which init system for Debian?

Posted Feb 5, 2014 22:58 UTC (Wed) by hummassa (guest, #307) [Link] (4 responses)

Nah, I don't think so. Exim and postfix and qmail etc. *do* have subtle differences.

And if some package needs not only a mailer, but -- for instance -- qmail, it's a matter just of packaging it depending on qmail specifically.

The same applies between systemd and upstart. The service files are automatically translatable between them (and openrc and sysvinit). If any package *needs* a specific one, it should just depend on this one. The package can even indicate its *preference* for one of them by way of
"Recommends:". No difference.

Which init system for Debian?

Posted Feb 6, 2014 1:08 UTC (Thu) by vonbrand (guest, #4458) [Link] (3 responses)

No, the configuration files certainly aren't translatable. Yes, upstart and systemd can run SysVinit scripts though the shell as a fallback. But native upstart (or systemd, for that matter) configurations express stuff that just can't be done in SysVinit (that is sort of the point of replacing SysVinit). In upstart dependencies are described by events, would need to untengle the whole "who triggers what" dependencies of the complete set to sort them into runlevels to get some approximation in SysVinit, and that would just go back to "cross fingers that the requisite stuff is already available" mantra. Systemd starts services mostly on demand, with some hand-configured dependencies. The dependencies could be sorted into runlevels, the "on first access" part definitively not. And the underlying models of upstart and systemd are too different for interoperation (systemd started precisely from scratch to solve fundamental problems with upstart's model).

Which init system for Debian?

Posted Feb 6, 2014 9:56 UTC (Thu) by hummassa (guest, #307) [Link] (2 responses)

If the most complete model is systemd's (and, in my assessment of the four init systems, yes it is), it is possible to emulate the same model (even if not perfectly) on the other init systems -- and at least the "systemd to upstart", "systemd to sysv", "systemd to openrc" are automatable or semi-automatable. Annotations could be done in comments in the systemd service files to help the "semi-" part.

Which init system for Debian?

Posted Feb 8, 2014 22:27 UTC (Sat) by smurf (subscriber, #17840) [Link] (1 responses)

Huh? If systemd can do everything the others can, then in theory the other config files can be translated to systemd, but not vice versa.

This is nontrivial even for shell scripts and would be a total mess to automate for upstart because systemd does not have (nor need) an event concept the way upstart has.

You can of course annotate a sysVinit or upstart script so that systemd can auto-translate it. But then you can write a systemd unit file from scratch just as easily, so why bother?

Which init system for Debian?

Posted Feb 8, 2014 22:52 UTC (Sat) by vonbrand (guest, #4458) [Link]

Both upstart and systemd can run SysVinit scripts for backward compatibility, so that point is moot.


Copyright © 2013, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds