Which init system for Debian?
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:
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:
- Stick with the existing sysvinit system.
- Systemd
- Upstart
- OpenRC
- 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.
Posted Nov 5, 2013 22:38 UTC (Tue)
by johannbg (guest, #65743)
[Link] (24 responses)
Posted Nov 5, 2013 23:21 UTC (Tue)
by robert.cohen@anu.edu.au (subscriber, #6281)
[Link] (23 responses)
So out of those options, I suppose openRC seems the most plausible.
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.
Posted Nov 5, 2013 23:55 UTC (Tue)
by wahern (guest, #37304)
[Link] (14 responses)
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?"
Posted Nov 6, 2013 1:41 UTC (Wed)
by josh (subscriber, #17465)
[Link] (8 responses)
Posted Nov 6, 2013 11:07 UTC (Wed)
by keeperofdakeys (guest, #82635)
[Link] (7 responses)
Posted Nov 7, 2013 7:50 UTC (Thu)
by ovitters (guest, #27950)
[Link] (6 responses)
Posted Nov 14, 2013 8:39 UTC (Thu)
by amtota (guest, #4012)
[Link] (1 responses)
Seeing how gnome seems to want to dictate everything, a little pushback sounds like positive thing to me!
Posted Nov 15, 2013 19:04 UTC (Fri)
by Company (guest, #57006)
[Link]
Because that's important to figure out before you talk about who is pushing whom back.
Posted Nov 23, 2013 0:26 UTC (Sat)
by sbergman27 (guest, #10767)
[Link] (3 responses)
Posted Nov 23, 2013 0:31 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link]
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.
Posted Nov 23, 2013 9:37 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (1 responses)
Posted Nov 24, 2013 12:32 UTC (Sun)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 6, 2013 6:57 UTC (Wed)
by epa (subscriber, #39769)
[Link] (1 responses)
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'.
Posted Nov 15, 2013 22:51 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
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,
Posted Nov 6, 2013 10:47 UTC (Wed)
by drago01 (subscriber, #50715)
[Link] (2 responses)
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.
Posted Nov 6, 2013 13:19 UTC (Wed)
by cwillu (guest, #67268)
[Link] (1 responses)
Posted Nov 6, 2013 16:10 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
Posted Nov 6, 2013 1:38 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Yeah -- When faced with a decision, Debian inevitably goes with "All of the above."
Posted Nov 6, 2013 2:06 UTC (Wed)
by rahvin (guest, #16953)
[Link] (6 responses)
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.
Posted Nov 6, 2013 13:26 UTC (Wed)
by Felix (subscriber, #36445)
[Link] (5 responses)
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.
Posted Nov 6, 2013 15:05 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
Posted Nov 6, 2013 15:09 UTC (Wed)
by HelloWorld (guest, #56129)
[Link]
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.
Posted Nov 15, 2013 20:07 UTC (Fri)
by HenrikH (subscriber, #31152)
[Link] (1 responses)
Posted Dec 3, 2013 12:42 UTC (Tue)
by SEMW (guest, #52697)
[Link]
Posted Nov 5, 2013 23:18 UTC (Tue)
by ballombe (subscriber, #9523)
[Link] (1 responses)
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.
Posted Nov 6, 2013 1:30 UTC (Wed)
by zuki (subscriber, #41808)
[Link]
Posted Nov 6, 2013 1:46 UTC (Wed)
by josh (subscriber, #17465)
[Link] (6 responses)
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.
Posted Nov 6, 2013 6:54 UTC (Wed)
by corsac (subscriber, #49696)
[Link] (1 responses)
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.
Posted Nov 6, 2013 12:32 UTC (Wed)
by josh (subscriber, #17465)
[Link]
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.
Posted Nov 6, 2013 11:47 UTC (Wed)
by error27 (subscriber, #8346)
[Link]
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.
Posted Nov 7, 2013 13:43 UTC (Thu)
by aba (guest, #24118)
[Link] (2 responses)
Posted Nov 9, 2013 6:51 UTC (Sat)
by lsl (subscriber, #86508)
[Link] (1 responses)
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. ;-)
Posted Nov 20, 2013 18:38 UTC (Wed)
by wookey (guest, #5501)
[Link]
Posted Nov 6, 2013 4:14 UTC (Wed)
by luya (subscriber, #50741)
[Link] (37 responses)
Posted Nov 6, 2013 7:50 UTC (Wed)
by tzafrir (subscriber, #11501)
[Link] (36 responses)
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 .
Posted Nov 6, 2013 12:36 UTC (Wed)
by josh (subscriber, #17465)
[Link] (35 responses)
(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.)
Posted Nov 6, 2013 13:20 UTC (Wed)
by tzafrir (subscriber, #11501)
[Link] (34 responses)
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.
Posted Nov 6, 2013 14:02 UTC (Wed)
by josh (subscriber, #17465)
[Link] (33 responses)
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).
Posted Nov 7, 2013 7:59 UTC (Thu)
by dgm (subscriber, #49227)
[Link] (32 responses)
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.
Posted Nov 7, 2013 12:41 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (29 responses)
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.
Posted Nov 7, 2013 15:02 UTC (Thu)
by Seegras (guest, #20463)
[Link] (1 responses)
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).
Posted Nov 7, 2013 21:05 UTC (Thu)
by HelloWorld (guest, #56129)
[Link]
Posted Nov 7, 2013 15:08 UTC (Thu)
by dgm (subscriber, #49227)
[Link] (18 responses)
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).
Posted Nov 7, 2013 16:51 UTC (Thu)
by andreasb (guest, #80258)
[Link]
> But you should. For the same reasons you should care about processors
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.
Posted Nov 7, 2013 22:13 UTC (Thu)
by HelloWorld (guest, #56129)
[Link] (16 responses)
> 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.
> But you should.
Posted Nov 11, 2013 14:23 UTC (Mon)
by dgm (subscriber, #49227)
[Link] (15 responses)
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.
Posted Nov 11, 2013 15:45 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (13 responses)
> My opinion is completely for me to judge.
Posted Nov 11, 2013 22:14 UTC (Mon)
by dlang (guest, #313)
[Link] (7 responses)
>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)
Posted Nov 11, 2013 23:29 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (6 responses)
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.
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.
Posted Nov 12, 2013 3:14 UTC (Tue)
by dlang (guest, #313)
[Link] (5 responses)
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
Posted Nov 12, 2013 9:55 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (4 responses)
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 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.
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.
Posted Nov 12, 2013 10:18 UTC (Tue)
by dlang (guest, #313)
[Link] (3 responses)
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.
Posted Nov 12, 2013 10:42 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (1 responses)
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.
Posted Nov 12, 2013 13:02 UTC (Tue)
by HelloWorld (guest, #56129)
[Link]
Posted Nov 20, 2013 22:53 UTC (Wed)
by josh (subscriber, #17465)
[Link]
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.
Posted Nov 13, 2013 17:38 UTC (Wed)
by ThinkRob (guest, #64513)
[Link] (4 responses)
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.
Posted Nov 13, 2013 19:28 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (3 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.
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.
Posted Nov 13, 2013 20:27 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
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.
Posted Nov 19, 2013 5:57 UTC (Tue)
by ThinkRob (guest, #64513)
[Link] (1 responses)
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.
Posted Nov 19, 2013 9:17 UTC (Tue)
by smurf (subscriber, #17840)
[Link]
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.
Posted Nov 15, 2013 23:01 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
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,
Posted Nov 10, 2013 14:11 UTC (Sun)
by Jandar (subscriber, #85683)
[Link] (3 responses)
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.
Posted Nov 10, 2013 17:41 UTC (Sun)
by raven667 (subscriber, #5198)
[Link]
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.
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.
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.
Posted Nov 14, 2013 7:22 UTC (Thu)
by kevinm (guest, #69913)
[Link] (3 responses)
(syscall filtering should be setup in the individual apps, by the way).
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?
Posted Nov 15, 2013 6:38 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (1 responses)
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.
Posted Nov 16, 2013 20:50 UTC (Sat)
by kleptog (subscriber, #1183)
[Link]
By all accounts systemd will do an even better job, though I've not had the opportunity to find out yet...
Posted Nov 7, 2013 13:49 UTC (Thu)
by josh (subscriber, #17465)
[Link] (1 responses)
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.
Posted Nov 7, 2013 14:55 UTC (Thu)
by dgm (subscriber, #49227)
[Link]
Posted Nov 6, 2013 7:06 UTC (Wed)
by ncm (guest, #165)
[Link] (6 responses)
Posted Nov 6, 2013 7:08 UTC (Wed)
by ncm (guest, #165)
[Link]
Posted Nov 6, 2013 7:30 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
Posted Nov 6, 2013 12:47 UTC (Wed)
by KSteffensen (guest, #68295)
[Link]
More info here:
Posted Nov 6, 2013 19:43 UTC (Wed)
by rbrito (guest, #66188)
[Link] (2 responses)
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).
Posted Nov 21, 2013 13:59 UTC (Thu)
by mirabilos (subscriber, #84359)
[Link] (1 responses)
Posted Nov 21, 2013 15:06 UTC (Thu)
by corbet (editor, #1)
[Link]
Posted Nov 6, 2013 8:29 UTC (Wed)
by dambacher (subscriber, #1710)
[Link] (2 responses)
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.
Posted Nov 6, 2013 9:55 UTC (Wed)
by hmh (subscriber, #3838)
[Link]
So, as far as Debian is concerned, the /usr/*bin versus /*bin, and bin versus sbin issues will become purely namespace issues.
Posted Nov 6, 2013 12:25 UTC (Wed)
by ovitters (guest, #27950)
[Link]
Not aware of any hateful discussion in Gentoo. I do see various Gentoo users raising the same things over and over again.
Posted Nov 6, 2013 12:37 UTC (Wed)
by jfasch (guest, #64826)
[Link] (9 responses)
Posted Nov 6, 2013 13:58 UTC (Wed)
by zuki (subscriber, #41808)
[Link] (5 responses)
Posted Nov 6, 2013 18:00 UTC (Wed)
by debacle (subscriber, #7114)
[Link] (4 responses)
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.
Posted Nov 6, 2013 18:13 UTC (Wed)
by ovitters (guest, #27950)
[Link]
Posted Nov 6, 2013 19:08 UTC (Wed)
by alexl (subscriber, #19068)
[Link]
Its on a page with "systemd" in the name, but the API is generic.
Posted Nov 8, 2013 18:54 UTC (Fri)
by drag (guest, #31333)
[Link] (1 responses)
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.
Posted Nov 9, 2013 7:51 UTC (Sat)
by tzafrir (subscriber, #11501)
[Link]
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.
Posted Nov 6, 2013 15:08 UTC (Wed)
by pbonzini (subscriber, #60935)
[Link] (2 responses)
Posted Nov 6, 2013 15:30 UTC (Wed)
by avheimburg (guest, #75272)
[Link]
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.
Posted Nov 6, 2013 15:31 UTC (Wed)
by jfasch (guest, #64826)
[Link]
Posted Nov 6, 2013 17:52 UTC (Wed)
by jengelh (guest, #33263)
[Link]
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.)
Posted Nov 7, 2013 1:33 UTC (Thu)
by Lukehasnoname (guest, #65152)
[Link] (3 responses)
>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.
Posted Nov 7, 2013 2:23 UTC (Thu)
by zuki (subscriber, #41808)
[Link]
So it's reasonable only if you limit yourself to small fixes here and there. Otherwise, it's just not worth the pain.
Posted Nov 7, 2013 14:33 UTC (Thu)
by debacle (subscriber, #7114)
[Link] (1 responses)
Posted Nov 8, 2013 17:12 UTC (Fri)
by intgr (subscriber, #39733)
[Link]
It's not as simple as "don't sign the agreement". Debian developers have two choices with Upstart:
Neither sounds like a good resolution.
Posted Nov 7, 2013 1:36 UTC (Thu)
by Lukehasnoname (guest, #65152)
[Link] (1 responses)
Posted Nov 7, 2013 12:02 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
Don't worry. The flamewar is brewing as I type...
Posted Nov 10, 2013 19:10 UTC (Sun)
by Jonno (subscriber, #49613)
[Link] (6 responses)
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?
Posted Nov 10, 2013 19:41 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
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.
Posted Nov 11, 2013 1:39 UTC (Mon)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Posted Nov 11, 2013 2:01 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Nov 12, 2013 23:22 UTC (Tue)
by intgr (subscriber, #39733)
[Link] (1 responses)
So sounds like that's in fact *not* a use case for Debian/kFreeBSD. ;)
Posted Nov 12, 2013 23:27 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 21, 2013 17:12 UTC (Thu)
by nye (subscriber, #51576)
[Link]
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.
Posted Nov 13, 2013 7:44 UTC (Wed)
by glaesera (guest, #91429)
[Link] (76 responses)
Posted Nov 13, 2013 9:06 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (74 responses)
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?
Posted Nov 13, 2013 13:44 UTC (Wed)
by hummassa (subscriber, #307)
[Link] (11 responses)
> 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...
Posted Nov 13, 2013 14:20 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
That problem is now resolved.
Posted Nov 13, 2013 14:20 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (5 responses)
Posted Dec 5, 2013 12:54 UTC (Thu)
by malor (guest, #2973)
[Link] (4 responses)
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.
Posted Dec 5, 2013 13:29 UTC (Thu)
by micka (subscriber, #38720)
[Link]
It's strange, I think this remark has already been done, with the same answer...
Posted Dec 5, 2013 13:30 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Dec 5, 2013 17:24 UTC (Thu)
by dlang (guest, #313)
[Link] (1 responses)
Posted Dec 5, 2013 17:30 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
[1]http://www.freedesktop.org/wiki/Software/systemd/Interfac...
Posted Nov 13, 2013 19:13 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (3 responses)
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 …"
Posted Nov 15, 2013 18:59 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
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.
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.
Posted Nov 15, 2013 23:50 UTC (Fri)
by nix (subscriber, #2304)
[Link]
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.
Posted Nov 14, 2013 12:51 UTC (Thu)
by paulj (subscriber, #341)
[Link] (61 responses)
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.
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).
Posted Nov 14, 2013 16:46 UTC (Thu)
by paulj (subscriber, #341)
[Link] (58 responses)
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.
Posted Nov 14, 2013 20:37 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (56 responses)
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.
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.
Posted Nov 14, 2013 22:04 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (3 responses)
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.
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, …)!
Posted Nov 14, 2013 22:34 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Nov 14, 2013 23:41 UTC (Thu)
by anselm (subscriber, #2796)
[Link]
Oh good. I wasn't quite sure :^)
Posted Nov 15, 2013 7:28 UTC (Fri)
by paulj (subscriber, #341)
[Link] (51 responses)
"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.
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?
Posted Nov 15, 2013 9:18 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link] (16 responses)
Posted Nov 15, 2013 14:14 UTC (Fri)
by paulj (subscriber, #341)
[Link] (15 responses)
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.
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«.
Posted Nov 15, 2013 15:47 UTC (Fri)
by khim (subscriber, #9252)
[Link] (13 responses)
Where LWN means “Linux Weekly News”. How can you disagree with truth? Yes, it's impossible and it's only possible with the “monolithic systemd way”. 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.
Posted Nov 15, 2013 19:03 UTC (Fri)
by nix (subscriber, #2304)
[Link] (9 responses)
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.
Posted Nov 15, 2013 23:51 UTC (Fri)
by nix (subscriber, #2304)
[Link] (5 responses)
Posted Nov 16, 2013 0:04 UTC (Sat)
by khim (subscriber, #9252)
[Link] (4 responses)
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?
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.
Posted Nov 16, 2013 6:44 UTC (Sat)
by spaetz (guest, #32870)
[Link]
xinetd might be a bicycle, but it does have electric motor and 21 gears...
Posted Nov 16, 2013 17:57 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (1 responses)
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.
Posted Dec 8, 2013 16:24 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Nov 16, 2013 9:42 UTC (Sat)
by paulj (subscriber, #341)
[Link] (1 responses)
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).
Posted Nov 16, 2013 14:27 UTC (Sat)
by raven667 (subscriber, #5198)
[Link]
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.)
Posted Nov 20, 2013 4:10 UTC (Wed)
by ThinkRob (guest, #64513)
[Link] (2 responses)
Posted Nov 20, 2013 4:43 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (1 responses)
Posted Nov 21, 2013 0:53 UTC (Thu)
by ThinkRob (guest, #64513)
[Link]
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.)
Posted Nov 15, 2013 17:26 UTC (Fri)
by smurf (subscriber, #17840)
[Link] (32 responses)
… 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).
Posted Nov 15, 2013 22:28 UTC (Fri)
by paulj (subscriber, #341)
[Link] (31 responses)
Posted Nov 16, 2013 17:30 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (30 responses)
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_.
Posted Nov 16, 2013 18:28 UTC (Sat)
by paulj (subscriber, #341)
[Link] (3 responses)
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. :)
Posted Nov 16, 2013 18:32 UTC (Sat)
by paulj (subscriber, #341)
[Link]
Posted Nov 16, 2013 19:45 UTC (Sat)
by smurf (subscriber, #17840)
[Link]
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 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.
Posted Nov 19, 2013 1:18 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Systemd solves this nicely by simply slaughtering anything within the service's cgroup.
Posted Nov 16, 2013 19:50 UTC (Sat)
by HelloWorld (guest, #56129)
[Link] (3 responses)
Posted Dec 8, 2013 16:27 UTC (Sun)
by nix (subscriber, #2304)
[Link] (2 responses)
Imagine, over a noisy phone line:
"What PID is that?"
(well, OK, that machine has been forking up a storm for implausibly long. But still. :) )
Posted Dec 8, 2013 17:25 UTC (Sun)
by andresfreund (subscriber, #69562)
[Link]
Posted Dec 8, 2013 19:18 UTC (Sun)
by smurf (subscriber, #17840)
[Link]
… 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?
Posted Nov 17, 2013 19:21 UTC (Sun)
by luto (guest, #39314)
[Link] (21 responses)
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.)
Posted Nov 17, 2013 20:13 UTC (Sun)
by raven667 (subscriber, #5198)
[Link] (20 responses)
Re: Control Groups
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.
Posted Nov 17, 2013 20:29 UTC (Sun)
by luto (guest, #39314)
[Link] (19 responses)
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.
Posted Nov 17, 2013 21:05 UTC (Sun)
by raven667 (subscriber, #5198)
[Link] (18 responses)
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
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.
Posted Nov 18, 2013 4:54 UTC (Mon)
by dlang (guest, #313)
[Link] (17 responses)
Posted Nov 18, 2013 5:36 UTC (Mon)
by luto (guest, #39314)
[Link] (16 responses)
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:
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).
Posted Nov 18, 2013 5:46 UTC (Mon)
by dlang (guest, #313)
[Link] (1 responses)
Posted Nov 18, 2013 6:04 UTC (Mon)
by luto (guest, #39314)
[Link]
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.)
Posted Nov 18, 2013 12:55 UTC (Mon)
by HelloWorld (guest, #56129)
[Link] (12 responses)
Posted Nov 20, 2013 15:34 UTC (Wed)
by foom (subscriber, #14868)
[Link] (11 responses)
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.
Posted Nov 20, 2013 22:43 UTC (Wed)
by HelloWorld (guest, #56129)
[Link] (10 responses)
Posted Nov 20, 2013 23:08 UTC (Wed)
by luto (guest, #39314)
[Link] (9 responses)
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: 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.
Posted Nov 20, 2013 23:57 UTC (Wed)
by rodgerd (guest, #58896)
[Link] (7 responses)
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*.
Posted Nov 21, 2013 5:35 UTC (Thu)
by luto (guest, #39314)
[Link] (5 responses)
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.
Posted Nov 21, 2013 6:10 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (2 responses)
Posted Nov 21, 2013 9:51 UTC (Thu)
by khim (subscriber, #9252)
[Link] (1 responses)
Posted Nov 21, 2013 13:06 UTC (Thu)
by hummassa (subscriber, #307)
[Link]
Posted Nov 21, 2013 19:26 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
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.
Posted Nov 21, 2013 21:01 UTC (Thu)
by intgr (subscriber, #39733)
[Link]
No, you got it backwards. They're saying that:
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).
Posted Nov 22, 2013 3:56 UTC (Fri)
by foom (subscriber, #14868)
[Link]
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?
Posted Nov 22, 2013 11:06 UTC (Fri)
by jezuch (subscriber, #52988)
[Link]
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).
Posted Nov 18, 2013 15:18 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
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.
Posted Nov 15, 2013 6:45 UTC (Fri)
by smurf (subscriber, #17840)
[Link]
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.
Posted Nov 13, 2013 14:22 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
Posted Nov 17, 2013 14:03 UTC (Sun)
by hadrons123 (guest, #72126)
[Link] (1 responses)
Its like matrix: "There is no spoon."
http://www.joachim-breitner.de/blog/archives/627-Breaking...
Posted Dec 8, 2013 16:35 UTC (Sun)
by nix (subscriber, #2304)
[Link]
Posted Dec 17, 2013 17:55 UTC (Tue)
by flohoff (guest, #32900)
[Link] (3 responses)
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.
Posted Dec 17, 2013 18:23 UTC (Tue)
by mpr22 (subscriber, #60784)
[Link]
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". 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.
Posted Dec 17, 2013 18:26 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
> 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).
Posted Dec 17, 2013 21:14 UTC (Tue)
by raven667 (subscriber, #5198)
[Link]
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)
Posted Feb 4, 2014 12:01 UTC (Tue)
by djzort (guest, #57189)
[Link] (9 responses)
Posted Feb 4, 2014 16:11 UTC (Tue)
by foom (subscriber, #14868)
[Link] (8 responses)
I do see how it being compared with upstart might make one think it was being insulted, though...
Posted Feb 4, 2014 23:34 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (7 responses)
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.
Posted Feb 5, 2014 1:32 UTC (Wed)
by foom (subscriber, #14868)
[Link] (6 responses)
I know others disagree, but how is the decision *obviously* postfix, even today?
Posted Feb 5, 2014 22:16 UTC (Wed)
by smurf (subscriber, #17840)
[Link] (5 responses)
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.
Posted Feb 5, 2014 22:58 UTC (Wed)
by hummassa (subscriber, #307)
[Link] (4 responses)
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
Posted Feb 6, 2014 1:08 UTC (Thu)
by vonbrand (subscriber, #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).
Posted Feb 6, 2014 9:56 UTC (Thu)
by hummassa (subscriber, #307)
[Link] (2 responses)
Posted Feb 8, 2014 22:27 UTC (Sat)
by smurf (subscriber, #17840)
[Link] (1 responses)
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?
Posted Feb 8, 2014 22:52 UTC (Sat)
by vonbrand (subscriber, #4458)
[Link]
Both upstart and systemd can run SysVinit scripts for backward compatibility, so that point is moot.
Which init system for Debian?
Which init system for Debian?
Also they clearly can't choose the same system as any other distribution.
Noone important uses that :-).
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
gnome?
gnome?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Linux is a monoculture?
Wol
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
The whole init debacle within Debian shows the complexity of adopting multiple kernels hindering the entire advance of Debian.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
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:
Which init system for Debian?
> Hurd ports.
Which init system for Debian?
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?
Which init system for Debian?
>> ports.
> 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?
Yeah, and my grandma somehow manages to live with no computer at all. What kind of argument is that supposed to be?
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.
I don't think that's for you to judge.
Which init system for Debian?
Which init system for Debian?
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.
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?
Which init system for Debian?
The only thing that people are objecting to is being forced to switch distros to avoid using systemd when they don't want it.
they object to distros being chnaged from Unix to LennartOS while keeping the same name
Which init system for Debian?
Which init system for Debian?
Debian already allows you to use systemd 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.
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?
Which init system for Debian?
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
Which init system for Debian?
https://github.com/akhilvij/systemd-to-sysvinit-converter
That project seems to have gone dormant about a year ago.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
> That's kinda my point. You're a power user. You write your own init scripts.
Which init system for Debian?
Which init system for Debian?
Wol
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
https://wiki.debian.org/systemd#Issue_.231:_sysvinit_vs._...
Which init system for Debian?
Which init system for Debian?
Oh please, this isn't kindergarten; can we please find a way to do without the silly personal attacks?
Which init system for Debian?
Can we have a discussion based on fact, please ?!
This would be a benefit for the whole *nix community!
/usr and boot-time
Can we have a discussion based on fact, please ?!
Dependency on systemd: why/where?
Can anyone point me to an answer please?
Dependency on systemd: why/where?
Dependency on systemd: why/where?
Dependency on systemd: why/where?
Dependency on systemd: why/where?
http://www.freedesktop.org/wiki/Software/systemd/logind/
Dependency on systemd: why/where?
Dependency on systemd: why/where?
Dependency on systemd: why/where?
Dependency on systemd: why/where?
Dependency on systemd: why/where?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
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.
Which init system for Debian?
Which init system for Debian?
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.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
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?
Which init system for Debian?
> (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-
Which init system for Debian?
Which init system for Debian?
In my case, attack surface, mostly. Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
[2]http://upstream-tracker.org/versions/systemd.html
[3]http://www.freedesktop.org/wiki/Software/systemd/dbus/
Which init system for Debian?
Which init system for Debian?
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...)
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
That particular aspect of systemd requires the service to be modified to support that mode of operation, doesn't it?
The refinement you mention could be implemented with those too.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
I was responding to anselm, in the comments of this LWN article.
I disagree only with saying that it's impossible, and 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.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
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.
Which init system for Debian?
Which init system for Debian?
*Sigh* There are two way to "socket-activate" a process.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
(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?
Which init system for Debian?
Which init system for Debian?
>> it has launched and knows their PIDs.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
"41921160436"
"*sigh*"
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
> It's ugly, it's prone to failure if the service fork-bombs, and it's a bit overcomplicated.
> It's a case of using a sledgehammer to drive in a thumbtack
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.
Which init system for Debian?
Which init system for Debian?
> it's nonportable and will never be portable
Which init system for Debian?
Indeed.
Which init system for Debian?
Enumerating processes in the subtree is already possible with /proc/PID/task/TID/children (currently hidden in CONFIG_CHECKPOINT_RESTORE).
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
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?
Which init system for Debian?
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.
I can't shake the feeling that this is an odd form of FUD from the systemd people.
Which init system for Debian?
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, ...
Which init system for Debian?
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.
Which init system for Debian?
Which init system for Debian?
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?
Which init system for Debian?
Which init system for Debian?
Assuming that anybody actually wants to do the work, which frankly I doubt – it'd be quite substantial.
Which init system for Debian?
1. Such a port would not be clean.
2. BSD developers wouldn't be interested in adopting systemd anyway.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
>> to support that mode of operation, doesn't it?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Who cares?
Who cares?
Who boots anyway? Last boot is probably a year ago.
Some deamon claiming ports it does not speak the protocol of - Wait what?!?
Who cares?
Who cares?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
And that Debian isn't afraid to do something that is different than others if it makes sense.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
"Recommends:". No difference.
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?
Which init system for Debian?