Debian committee members vote for systemd as init system(lists.debian.org)
lists.debian.org
Debian committee members vote for systemd as init system
https://lists.debian.org/debian-ctte/2014/02/msg00294.html
151 comments
It works perfectly in chrome. I don't know what's with the obnoxious yellow banner - I thought firefox people were against the "best viewed in internet explorer" attitude.
Works fine in IE 11 as well.
I didn't know there was a block of "firefox people", or that everyone developing for firefox was a member and shared the opinions they have.
Where's their mailing list/forum?
Where's their mailing list/forum?
That was absolutely great, and it is fascinating how the animated storytelling makes a complicated, lengthy debate so much more accessible.
I wonder if other complicated debates, especially political, could be presented in such a format, and if this would have a positive effect for informed democracy?
I wonder if other complicated debates, especially political, could be presented in such a format, and if this would have a positive effect for informed democracy?
Heh. This is the power of the Visual Novel medium! :)
This is the second part: http://aceattorney.sparklin.org/jeu.php?id_proces=57899
Unfortunately, the second part seems to get stuck in "cross examination" and it's impossible to continue.
Does it? It's a Phoenix Wright game. You have to press and present evidence.
EDIT: You're right. Pressing each statement yields more dialogue, but without evidence, you can't progress.
EDIT: You're right. Pressing each statement yields more dialogue, but without evidence, you can't progress.
It's clearly still a work in progress and incomplete. Wait, I'm sure it'll be extended.
That is glorious. And several of the characters match very well, particularly Russ as Phoenix and Bdale as the Judge.
That was incredible. How was the dialogue compiled? Was it copied verbatim from mailing list discussions, or was it paraphrased?
That is huge though. I felt I was spending way too much time watching this and hoped it was getting to a close, while I around message 250 out of 700. (Of part 1 it seems?!)
Yeah, endless debate. Welcome to Debian decision-making. :-)
Well the visual way in which it's shown makes it easier to follow without knowing people by name, but also makes it take much longer to read it all. There are like 80 characters per message before you have to click continue or hit enter.
I'd say the discussion is a good/fun thing to present in this form, but abbreviated.
I'd say the discussion is a good/fun thing to present in this form, but abbreviated.
:)
That thing is unbelievably more awesome than I would otherwise have assumed.
Who made this (and part 2)? How can I find out if any more parts are made?
Who made this (and part 2)? How can I find out if any more parts are made?
Apparently it was made by Dainius Masiliūnas (http://greatemerald.xmpcommunity.com/), who seems to be active in the Phoronix forums: http://www.phoronix.com/forums/member.php?17103-GreatEmerald
[deleted]
That was great, thank you!
Not a surprise, was there a compelling reason for upstart at all?
Not that I can think of. Upstart is slightly simpler than systemd to build configuration files for, but that's also because it doesn't have any advanced features like memory/processor/IO limits or the like. Additionally it doesn't even properly manage child processes... so you have to use wrappers to get Unicorn management working right in Upstart.
Upstart took years to add support for setuid/setgrp and still doesn't have basic features like a respawn delay which shipped in launchd (or 90s inetd) before upstart was released. There's still no integrated way to reliably kill malfunctioning child processes and the commands will block until success so you're going to need to kill -9 a lot when e.g. adjusting a script for a daemon which forks.
I was rooting for upstart for years but it's hard to take seriously as a project when basic sysadmin tasks are still gratuitously hard / unreliable.
I was rooting for upstart for years but it's hard to take seriously as a project when basic sysadmin tasks are still gratuitously hard / unreliable.
>still doesn't have basic features like a respawn delay
What are you talking about?
http://upstart.ubuntu.com/cookbook/#respawn-limit
What are you talking about?
http://upstart.ubuntu.com/cookbook/#respawn-limit
That's unusafe in production: unless you have a very short-duration problem it'll retry a few times and then pretend you wanted the process stopped. Something like a down database or NFS server will still require you to restart everything in a cluster outside of upstart.
They should have copied prior art from launchd or some inetd implementations where the delay has a back off mechanism with some configurable min/max limits.
They should have copied prior art from launchd or some inetd implementations where the delay has a back off mechanism with some configurable min/max limits.
Agreed. The inability to specify a restart delay is just silly. It makes that functionality only useful for OOM type issues where the main process dies unexpectedly. Network transition type problems and you're going to have-a-bad-time.
Yeah – things like that or needing a number of major releases before getting reliable console support, setuid/gid, restart not implying start, etc. left me wondering if any actual sysadmins were involved in the development. Most of these would have been on my group's list of basic 1.0 requirements…
You can specify a respawn delay. Please read the cookbook.
Upstart can set resource limits on anything setrlimit(2) offers, including memory and processor. It's not as flexible or reliable as systemd's use of control groups, though.
Systemd isn't portable to non-linux. (And while you may not care about debian kfreebsd, some people do)
There are no working ports of upstart to non-linux, and up until 2 months ago no-one was even trying to. It's about as portable as systemd (i.e. with a bunch of work and if you don't mind forking it).
The difference is that upstream for upstart is open to BSD/Hurd/etc. ports, whereas upstream for systemd is pretty strongly opposed to them and it does not seem they would assist in the effort.
As long as you are willing to sign the copyright license agreement,
which was one of the reasons systemd was started instead of improving upstart.
The upstream is GPL + CLA. From a Debian perspective that's something of a non-starter. You could fork it, but then you're in the same position as you would be with systemd.
Moreover systemd has defined a bunch of stable interfaces; one could choose to expose equivalent interfaces in the HURD rather than port. Upstart seems to be in the "implementation = interface" camp.
Moreover systemd has defined a bunch of stable interfaces; one could choose to expose equivalent interfaces in the HURD rather than port. Upstart seems to be in the "implementation = interface" camp.
If I were to port systemd to non-linux I wouldn't fork it. I would re-implement its interfaces (which are fairly stable and well-documented).
systemd fairly strongly depends on linux cgroups for process monitoring and management, no? I don't believe there's a suitable analog in any of the BSDs.
BSD has jails and rctl for controlling users resources limits and other analogous tools for process monitoring. The issue is systemd was not designed with portability in mind. Taking full advantage of Linux's features is fine for some distros, but Debian's philosophy has always been grounded in stability and portability.
Upstart was created before systemd.
Edit: Upstart was a great sysvinit replacement, at least during those years before systemd appeared.
Edit: Upstart was a great sysvinit replacement, at least during those years before systemd appeared.
upstart was always a mediocre to terrible sysv replacement. The fact it couldn't handle such insignificant programs like postfix natively speaks volumes.
When I wrote "replacement", I didn't mean that all sysv scripts must be replaced. Postfix sysv script works fine with upstart, doesn't it?
> When I wrote "replacement", I didn't mean that all sysv scripts must be replaced. Postfix sysv script works fine with upstart, doesn't it?
I'm honestly not sure if you are making fun of upstart or if you're trying to say that having to keep a sysv compatibility mode around because upstart is not able to handle an extremely common daemon is somehow acceptable.
I'm honestly not sure if you are making fun of upstart or if you're trying to say that having to keep a sysv compatibility mode around because upstart is not able to handle an extremely common daemon is somehow acceptable.
Sure, if you consider it "fine" that upstart is too broken to reliably run a reasonably standard and fairly important daemon in native mode.
sysv init was created before upstart, so it clearly must be even better? Your argument makes no sense...
systemd breaks LXC and lmctfy. systemd is not event based (matter of taste, I guess, but I prefer Upstart's model).
Looking at to the Arch wiki (https://wiki.archlinux.org/index.php/Lxc-systemd) it seems like LXC can be at least partially reconciled with systemd. Are there any features of LXC that absolutely can't be made to work with systemd?
[deleted]
What are you talking about? CoreOS uses docker + systemd extensively and docker is just a pretty wrapper ontop of lxc.
https://coreos.com/docs/launching-containers/launching/getti...
https://coreos.com/docs/launching-containers/launching/getti...
systemd post 204 requires that it is the only cgroups writer, and tramples over every other writer. Some have said that this is because of a decision by upstream kernel maintainers to allow only one cgroups writer, but this decision has not yet happened. Do you know what version of systemd coreOS uses?
I don't use coreos/systemd but some people run into issues like this: https://github.com/dotcloud/docker/issues/3629
Well, that involves running a weird nested stack: The CoreOS systemd, wrapped around a bunch of docker instances, one of which is trying to run the arch Linux systemd inside the container as well.
For what it's worth, Docker containers are generally not complete running machines with their own init system. Instead, they're typically a single top-level process running in an isolated container. Basically, they work more like a Heroku app than complete EC2 machine image.
For what it's worth, Docker containers are generally not complete running machines with their own init system. Instead, they're typically a single top-level process running in an isolated container. Basically, they work more like a Heroku app than complete EC2 machine image.
Exactly. I don't expect Upstart or even SysV init (in the configuration as provided by distributions) to work well inside Docker either.
For an example how you should build a Docker container, take a look at http://phusion.github.io/baseimage-docker/
For an example how you should build a Docker container, take a look at http://phusion.github.io/baseimage-docker/
Those are the votes for systemd:
https://lists.debian.org/debian-ctte/2014/02/msg00294.html
https://lists.debian.org/debian-ctte/2014/02/msg00283.html
https://lists.debian.org/debian-ctte/2014/02/msg00297.html
https://lists.debian.org/debian-ctte/2014/02/msg00282.html
For anyone wondering, 4 votes are enough because Bdale's vote (the chairman of the Technical Committee) count as two votes in case of a draw.
EDIT: see this (https://news.ycombinator.com/item?id=7203479) comment below - if the other 4 members of the TC vote F, then systemd would not win.
https://lists.debian.org/debian-ctte/2014/02/msg00294.html
https://lists.debian.org/debian-ctte/2014/02/msg00283.html
https://lists.debian.org/debian-ctte/2014/02/msg00297.html
https://lists.debian.org/debian-ctte/2014/02/msg00282.html
For anyone wondering, 4 votes are enough because Bdale's vote (the chairman of the Technical Committee) count as two votes in case of a draw.
EDIT: see this (https://news.ycombinator.com/item?id=7203479) comment below - if the other 4 members of the TC vote F, then systemd would not win.
It's not quite as simple as that, because if all the remaining committee members vote F (further discussion) ahead of D (systemd) then D gets dropped before the casting vote stage (Debian constitution A.6.3).
So far one of the four remaining committee members has done this, another is expected to, leaving the decisions of the remaining two to determine whether the vote completes or not.
So far one of the four remaining committee members has done this, another is expected to, leaving the decisions of the remaining two to determine whether the vote completes or not.
Sorry for spreading misinformation, it seems that I got exited too soon. Still, I find somewhat unlikely that all the others member will vote F ahead of D.
Are you referring to the "Technical Committee makes decisions only as last resort." paragraph of the Debian constitution? It's a bit cryptic for a non-native like me, so I'm not sure that I'm reading it right.
Are you referring to the "Technical Committee makes decisions only as last resort." paragraph of the Debian constitution? It's a bit cryptic for a non-native like me, so I'm not sure that I'm reading it right.
No, this is in the voting section A. It reads "Any (non-default) option which does not defeat the default option by its required majority ratio is dropped from consideration."
In this case F (further discussion) is the default option, and this stage in the voting process precedes the casting vote.
I too think it's unlikely that both Colin and Andi will block the decision, but we've known it's likely that systemd will win for some time now. It's still not yet official.
edit: actually there are other possible outcomes, see https://lists.debian.org/debian-ctte/2014/02/msg00309.html
In this case F (further discussion) is the default option, and this stage in the voting process precedes the casting vote.
I too think it's unlikely that both Colin and Andi will block the decision, but we've known it's likely that systemd will win for some time now. It's still not yet official.
edit: actually there are other possible outcomes, see https://lists.debian.org/debian-ctte/2014/02/msg00309.html
Looks like it's clear now. Colin Watson voted for Upstart[1], so systemd wins.
[1] https://lists.debian.org/debian-ctte/2014/02/msg00332.html
[1] https://lists.debian.org/debian-ctte/2014/02/msg00332.html
Indeed. Note that the reason systemd wins is that Colin voted systemd ahead of further discussion, now defeating it with at least 5 votes from the 8. And then in the subsequent voting stage systemd has at least 4 votes + the chair's casting vote as per the above post.
Fwiw, the only other vote that's been cast so far, which is in the other direction (3 people haven't yet voted): https://lists.debian.org/debian-ctte/2014/02/msg00288.html
To be fair he is also the Ubuntu developer and upstart maintainer on the committee
I agree with that vote. Since Debian is still committed to BSD, they aren't going to drop sysvint once the next-gen init system is in place.
Everybody, get your popcorn: https://lists.debian.org/debian-ctte/2014/02/msg00344.html
[deleted]
I wonder how long upstart will survive in Ubuntu after the next Debian stable
Probably a while, Ubuntu isn't too prone to changing things just because Debian (upstream) decided to do something.
Having Debian switch to systemd by default has no bearing on the preferred init system in Ubuntu.
What happened to the last vote? I saw some criticism that Ian jumped the gun by calling for votes when he did and putting two issues on at once but haven't read the archive in the meantime.
Pretty unfortunate it took this long. Even as a casual observer it's looked like they'd eventually pick systemd a month ago. Hopefully this vote is the last one.
Pretty unfortunate it took this long. Even as a casual observer it's looked like they'd eventually pick systemd a month ago. Hopefully this vote is the last one.
> What happened to the last vote?
Steve Langasek objected to the wording of the "tight coupling" and "loose coupling" options, and several others on the committee decided to vote Further Discussion first in response to that. It turns out that Steve (upstart maintainer) and Russ (primary systemd advocate on the committee) both agree fairly closely on that issue, in that the committee really shouldn't be ruling on that question in that way.
Steve Langasek objected to the wording of the "tight coupling" and "loose coupling" options, and several others on the committee decided to vote Further Discussion first in response to that. It turns out that Steve (upstart maintainer) and Russ (primary systemd advocate on the committee) both agree fairly closely on that issue, in that the committee really shouldn't be ruling on that question in that way.
It seems like that's the fundamental split between Ian and Everyone Else. Russ, Bdale, Steve, and Colin all want to make sure that people don't start creating unreasonable dependency chains ("I want the functionality provided by logind for my DE, therefore I will require systemd as the init system") when alternatives are available ("I need the functionality provided by logind so I require that and let systemd or the Canonical fork of logind provide it").
Ian is speccing it out so that nothing may ever rely on capabilities provided by a init implementation unless the Debian developers add that functionality to every possible init system in the archive. That is a very odd position, to put it mildly (you couldn't e.g. ship a GUI tool to manage upstart. You'd have to rewrite it to support systemd, as well).
Ian is speccing it out so that nothing may ever rely on capabilities provided by a init implementation unless the Debian developers add that functionality to every possible init system in the archive. That is a very odd position, to put it mildly (you couldn't e.g. ship a GUI tool to manage upstart. You'd have to rewrite it to support systemd, as well).
So when are they going to vote on whether to switch to RPM?
When RedHat decides to switch to DEB
And why would Reshat want to move to a clearly inferior solution? Next you'll say they want to replace the super simple kickstart with preseed. Blasphemy I say!
To be fair, it did take me 15 minutes to write my first RPM. Documentation is pretty good.
Writing my first Debian package, on the other hand, took me a day. Documentation is horrible. All tutorials are outdated. All the documents throw tons of jargon at me and just expect that I understand them. The tooling consists of 300 different tools with a lot of overlapping functionality, mostly for historical and backward-compatibility reasons. Debuilder, pbuilder, dpkg-buildpackage, debhelper, cbbs.... what? Learning all this stuf was a nightmare, while RPM was pretty straightforward.
Furthermore, Debian packaging tools don't have a preprocessor. It seems they really expect me to repackage my app separately for every distribution version. RPM on the other hand has a builtin preprocessor so that I can customize my specfile on a per-distribution basis with only a single file and a single tool. I ended up writing my own preprocessor for Debian packages, but something tells me I shouldn't have to.
On the other hand, RPM does not support "Recommended" and "Suggested" dependencies which are very useful. Neither does it support OR statements in dependency specifications. This latter sucks, a lot.
Writing my first Debian package, on the other hand, took me a day. Documentation is horrible. All tutorials are outdated. All the documents throw tons of jargon at me and just expect that I understand them. The tooling consists of 300 different tools with a lot of overlapping functionality, mostly for historical and backward-compatibility reasons. Debuilder, pbuilder, dpkg-buildpackage, debhelper, cbbs.... what? Learning all this stuf was a nightmare, while RPM was pretty straightforward.
Furthermore, Debian packaging tools don't have a preprocessor. It seems they really expect me to repackage my app separately for every distribution version. RPM on the other hand has a builtin preprocessor so that I can customize my specfile on a per-distribution basis with only a single file and a single tool. I ended up writing my own preprocessor for Debian packages, but something tells me I shouldn't have to.
On the other hand, RPM does not support "Recommended" and "Suggested" dependencies which are very useful. Neither does it support OR statements in dependency specifications. This latter sucks, a lot.
Fully agreed. I don't really like the RPM format, though, it's a glorified makefile which makes it inconvenient to generate in an automated fashion. Though, from what I can see, the Debian maintainers have done a good effort at bringing together the various packaging resources in a single document [1]. And, well, packaging is a complicated topic.
1: http://www.debian.org/doc/manuals/maint-guide/
1: http://www.debian.org/doc/manuals/maint-guide/
Clearly boh redhat and debian should switch to the even superior slackware txz.
Could somebody explain like I'm five?
I would start with K900's rundown here:
http://www.reddit.com/r/linux/comments/132gle/eli5_the_syste...
More on the Debian debate: https://wiki.debian.org/Debate/initsystem/upstart
And the Phoronix has a good overview of how this is playing out: http://www.phoronix.com/scan.php?page=news_item&px=MTU1NjA
http://www.phoronix.com/scan.php?page=news_item&px=MTQ5NzQ
More on the Debian debate: https://wiki.debian.org/Debate/initsystem/upstart
And the Phoronix has a good overview of how this is playing out: http://www.phoronix.com/scan.php?page=news_item&px=MTU1NjA
http://www.phoronix.com/scan.php?page=news_item&px=MTQ5NzQ
I second... Wannabe hacker and don't understand
A Linux operating system has a core program called a kernel, which has the job of creating and maintaining an environment where other programs can run. Other programs include the login prompt, the shell that lets you execute programs, etc. However, there is a chicken-and-the-egg problem: once the environment is running, how do you run the first program? This is solved by having the Linux kernel run a program called "init" as the first program, which manages everything else (bringing up services, executing the login prompt, etc). There are multiple versions of this "init" program with different features and idiosyncrasies -- the Debian committee voted to use one called systemd rather than some competitors. Switching versions of init requires system administrators to relearn how to do many things, so the committee spent a lot of time weighing a lot of factors before making this decision.
A group of programmers who make a popular version of Linux have decided to make their version of Linux start with a new program when the computer boots. Instead of using a program from the 80's called "System V init scripts", they have decided to switch to a new program called "systemd." Both programs have the major responsibility of starting the rest of the programs that make up Linux.
I found this explanation of systemd interesting (though more suitable for a wannabe hacker than a 5-year-old (though I suppose the two sets may not be disjoint)): http://0pointer.de/blog/projects/systemd.html
I found this explanation of systemd interesting (though more suitable for a wannabe hacker than a 5-year-old (though I suppose the two sets may not be disjoint)): http://0pointer.de/blog/projects/systemd.html
This might be a helpful explainer:
http://meetings-archive.debian.net/pub/debian-meetings/2013/...
http://meetings-archive.debian.net/pub/debian-meetings/2013/...
Can anyone give a quick rundown of the different init systems?
For the most part it can get confusing for a non day to day system administrator when I am trying to get a program to "run on boot". Between rc.local, init.d, run levels, etc. sometimes it is just frustrating.
For the most part it can get confusing for a non day to day system administrator when I am trying to get a program to "run on boot". Between rc.local, init.d, run levels, etc. sometimes it is just frustrating.
I know less about the new Linux ones, but a brief summary of the two big "traditional" ones:
Linux systems traditionally use "SysV Init", the init system from AT&T UNIX System V (1983). It's the one that has: 1) run levels; and 2) a pile of shell scripts in /etc/init.d that run on run-level changes. Run levels probably make most sense if you think of Ye Olde Mainframe booting: first it initializes core services, then it enters multi-user mode, then it initializes network services, then (optionally) it enters full application mode. These are supposed to be discrete, semantically meaningful boot levels that you could purposely initiate: boot to runlevel 1, boot to runlevel 2, drop back to runlevel 1. Dependencies are handled by a mixture of those runlevels, and scripts that are run in alphabetical order within run levels. That ordering (unlike runlevels) is not supposed to be meaningful to the sysop, but just necessity-based: some stuff depends on other services already being started, even if conceptually you want them all "at once". The convention is to prefix startup-script filenames with numbers that effectively serve as priorities within a runlevel.
BSD systems traditionally use their own "BSD init". There are no runlevels, though there is still a separate "single-user mode" for maintenance. In classic BSD startup was just one very large shell script in /etc/rc. In later versions it was augmented by an /etc/rc.local script that allowed local modifications to be made without mucking with the main script. Modern BSDs (starting with NetBSD, later adopted by the others) modularized it, with an /etc/rc.d directory (base system) and /usr/local/etc/rc.d/ directory (ports). This differs from SysV init in that it still has no run levels, and rather than explicit ordering via filename sorting, has dependency-resolution ordering via semantic comments at the top of each script that are parsed and resolved by rcorder(8) (http://www.freebsd.org/cgi/man.cgi?query=rcorder&sektion=8). Afaik this system, originating in NetBSD, was the first dependency-based startup system on a free Unix (I believe commercial Unixes like Solaris also moved to dependency-based init in the 2000s).
Many Linux vendors have decided that SysV Init is not such a nice system nowadays, because it involves maintaining fairly complex scripts with edge cases that have to be handled in every script through error-prone boilerplate, and an explicit global startup ordering: all programs that can be installed on Debian and need startup must be assigned an integer that fully specifies their position in the startup sequence relative to all other programs that might also be installed. Runlevels as a mechanism also seem pretty unhelpful for most uses people have nowadays. Instead there is a hope for some kind of dependency-based startup. But the big disagreement is over what to replace it with. It is also complicated by other changes that are happening in parallel and which are caught up in it. For example, Linux's 'cgroups' resource-control mechanism has long been in the kernel, but not widely used by userspace tools, and there are moves to sort out this situation by essentially letting the init system also own resource assignments, which would more tightly couple those components. This is probably where the big philosophical differences come in.
Linux systems traditionally use "SysV Init", the init system from AT&T UNIX System V (1983). It's the one that has: 1) run levels; and 2) a pile of shell scripts in /etc/init.d that run on run-level changes. Run levels probably make most sense if you think of Ye Olde Mainframe booting: first it initializes core services, then it enters multi-user mode, then it initializes network services, then (optionally) it enters full application mode. These are supposed to be discrete, semantically meaningful boot levels that you could purposely initiate: boot to runlevel 1, boot to runlevel 2, drop back to runlevel 1. Dependencies are handled by a mixture of those runlevels, and scripts that are run in alphabetical order within run levels. That ordering (unlike runlevels) is not supposed to be meaningful to the sysop, but just necessity-based: some stuff depends on other services already being started, even if conceptually you want them all "at once". The convention is to prefix startup-script filenames with numbers that effectively serve as priorities within a runlevel.
BSD systems traditionally use their own "BSD init". There are no runlevels, though there is still a separate "single-user mode" for maintenance. In classic BSD startup was just one very large shell script in /etc/rc. In later versions it was augmented by an /etc/rc.local script that allowed local modifications to be made without mucking with the main script. Modern BSDs (starting with NetBSD, later adopted by the others) modularized it, with an /etc/rc.d directory (base system) and /usr/local/etc/rc.d/ directory (ports). This differs from SysV init in that it still has no run levels, and rather than explicit ordering via filename sorting, has dependency-resolution ordering via semantic comments at the top of each script that are parsed and resolved by rcorder(8) (http://www.freebsd.org/cgi/man.cgi?query=rcorder&sektion=8). Afaik this system, originating in NetBSD, was the first dependency-based startup system on a free Unix (I believe commercial Unixes like Solaris also moved to dependency-based init in the 2000s).
Many Linux vendors have decided that SysV Init is not such a nice system nowadays, because it involves maintaining fairly complex scripts with edge cases that have to be handled in every script through error-prone boilerplate, and an explicit global startup ordering: all programs that can be installed on Debian and need startup must be assigned an integer that fully specifies their position in the startup sequence relative to all other programs that might also be installed. Runlevels as a mechanism also seem pretty unhelpful for most uses people have nowadays. Instead there is a hope for some kind of dependency-based startup. But the big disagreement is over what to replace it with. It is also complicated by other changes that are happening in parallel and which are caught up in it. For example, Linux's 'cgroups' resource-control mechanism has long been in the kernel, but not widely used by userspace tools, and there are moves to sort out this situation by essentially letting the init system also own resource assignments, which would more tightly couple those components. This is probably where the big philosophical differences come in.
> (I believe commercial Unixes like Solaris also moved to dependency-based init in the 2000s).
You are correct. Solaris 10 introduced SMF (http://docs.oracle.com/cd/E23824_01/html/821-1451/dzhid.html...), which kicks quite a bit of ass.
Services are defined in XML files called manifests, which specify dependencies (including filesystems and network connectivity), the user and group to run as, timeouts for start/stop, and a bunch of other stuff.
The cool part is that, while the manifest files are static, SMF doesn't actually use them directly. The service definitions get slurped into a DB, and you can change properties (such as the whether or not the service is enabled, the user to run as, and pretty much anything else the manifest author thought of) on the fly, without editing a manifest or mucking with symlinks.
SMF also starts services in parallel (Solaris/OpenSolaris boot really, really quickly), and services that die are automatically restarted (so long as they're dying again too quickly).
You are correct. Solaris 10 introduced SMF (http://docs.oracle.com/cd/E23824_01/html/821-1451/dzhid.html...), which kicks quite a bit of ass.
Services are defined in XML files called manifests, which specify dependencies (including filesystems and network connectivity), the user and group to run as, timeouts for start/stop, and a bunch of other stuff.
The cool part is that, while the manifest files are static, SMF doesn't actually use them directly. The service definitions get slurped into a DB, and you can change properties (such as the whether or not the service is enabled, the user to run as, and pretty much anything else the manifest author thought of) on the fly, without editing a manifest or mucking with symlinks.
SMF also starts services in parallel (Solaris/OpenSolaris boot really, really quickly), and services that die are automatically restarted (so long as they're dying again too quickly).
Whoa! You aren't bashing any of them and the explanation is 100% correct! WHAT HAS THE INTERNETS COME TO?
Congratulations on a very well-written summary!
Congratulations on a very well-written summary!
Not so loud, they'll hear you!
WHAT HAS THE INTERNETS COME TO?
The way it was supposed to be?
The way it was supposed to be?
Debian already has dependency based boot based on magic comments at the top for their syvinit scripts. The program used is called insserv and is something they got from Suse.
I am just going to go over Upstart and systemd
systemd: dependency based init system. A service is written by declaring which services need to be started for that service to start. It is also a syslog like program (journal) and a cgroups writer (cgroups are a cointainment feature of the linux kernel). It also features socket activated and bus activated services, where the init system watches for a socket or dbus bus to be accessed, and then starts the job then. It is criticized for being too invasive and too tied to linux kernel features (like cgroups).
Upstart: an event based init system. Jobs start and stop on a certain event (or events). These events can be socket events, dbus events, udev events (network-device-added, removed, changed, etc.) or job events ($JOB-started, stopped, starting, stopping). There are also other events, but those are the basics. It suffers in two areas: socket activation is limited to one tcp or unix socket (no UDP, no tcp6, no DGRAM), and it unreliably stops services. The former is a simple problem that would not be too much work to fix (the developers of Upstart did not want to use socket activation, so they decided to stop efforts on developing it), and the latter is a fundamental code problem. Upstart uses ptrace to track daemons, while systemd uses pidfiles and cgroups. Because Upstart does not use cgroups, it can not kill all of a services children (just that service), and so zombie services might be problematic.
systemd: dependency based init system. A service is written by declaring which services need to be started for that service to start. It is also a syslog like program (journal) and a cgroups writer (cgroups are a cointainment feature of the linux kernel). It also features socket activated and bus activated services, where the init system watches for a socket or dbus bus to be accessed, and then starts the job then. It is criticized for being too invasive and too tied to linux kernel features (like cgroups).
Upstart: an event based init system. Jobs start and stop on a certain event (or events). These events can be socket events, dbus events, udev events (network-device-added, removed, changed, etc.) or job events ($JOB-started, stopped, starting, stopping). There are also other events, but those are the basics. It suffers in two areas: socket activation is limited to one tcp or unix socket (no UDP, no tcp6, no DGRAM), and it unreliably stops services. The former is a simple problem that would not be too much work to fix (the developers of Upstart did not want to use socket activation, so they decided to stop efforts on developing it), and the latter is a fundamental code problem. Upstart uses ptrace to track daemons, while systemd uses pidfiles and cgroups. Because Upstart does not use cgroups, it can not kill all of a services children (just that service), and so zombie services might be problematic.
> Because Upstart does not use cgroups, it can not kill all of a services children (just that service), and so zombie services might be problematic.
from my (very limited) experience with upstart, even the upstart scripts themselves can get into a unrecoverable zombie state[1], where the only workaround is to do one of the following 1) reboot ; 2) run some crazy-ass script[2] that forks processes until the right pid is grabbed to then kill it ; 3) rename the upstart script
[1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/10433... [2] https://gist.github.com/mitsuhiko/d55199e9b1ad7fc65504
from my (very limited) experience with upstart, even the upstart scripts themselves can get into a unrecoverable zombie state[1], where the only workaround is to do one of the following 1) reboot ; 2) run some crazy-ass script[2] that forks processes until the right pid is grabbed to then kill it ; 3) rename the upstart script
[1] https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/10433... [2] https://gist.github.com/mitsuhiko/d55199e9b1ad7fc65504
You should use init-checkconf before enabling the scripts.
Thanks for the tip. An init system that gets itself into such a fragile position is a signal that something isn't quite right (not to mention there was not even a response to this bug report, which isn't a great sign either)
I have used ptrace and cgroup (in an online judge system). The cgroup way feels more correct and stable while ptrace feels a hack. The usage of ptrace and SIGSTOP in upstart looks pretty ugly to me.
SIGSTOP is actually pretty clean, but it takes away some debugging methods from the sysadmin. Please note that systemd uses PID files to track services, which is an incredibly horrible method (although not as bad as ptrace).
Just my two cents as I haven't seen it mentioned in this thread:
launchd is the init system used by Mac OSX and has been ported to FreeBSD a few years ago with a recent resurgent effort for improvements [1]. It has been suggested that launchd could one day be the new FreeBSD init system due to speed and feature improvements, but many FreeBSD users think that the init system is a non-issue and efforts could be better spent elsewhere. launchd has also been criticized as to have been developed for OSX and not BSD (e.g. it depends on CoreFoundation features).
There is growing concern that applications will become more reliant on systemd and therefore Linux-only features [2], reducing or eliminating portability to the BSDs. Unfortunately, most conversations about init systems and FreeBSD degenerate into flame wars [3].
[1]: https://github.com/rtyler/openlaunchd
[2]: http://people.debian.org/~stapelberg//2013/07/13/systemd-not...
[3]: http://forums.freebsd.org/viewtopic.php?t=35770
launchd is the init system used by Mac OSX and has been ported to FreeBSD a few years ago with a recent resurgent effort for improvements [1]. It has been suggested that launchd could one day be the new FreeBSD init system due to speed and feature improvements, but many FreeBSD users think that the init system is a non-issue and efforts could be better spent elsewhere. launchd has also been criticized as to have been developed for OSX and not BSD (e.g. it depends on CoreFoundation features).
There is growing concern that applications will become more reliant on systemd and therefore Linux-only features [2], reducing or eliminating portability to the BSDs. Unfortunately, most conversations about init systems and FreeBSD degenerate into flame wars [3].
[1]: https://github.com/rtyler/openlaunchd
[2]: http://people.debian.org/~stapelberg//2013/07/13/systemd-not...
[3]: http://forums.freebsd.org/viewtopic.php?t=35770
systemd is basically launchd for Linux (and only Linux). The systemd devs make no apology about the launchd inspiration.
IIRC, when a presentation a few years ago at Chaos Communication Congress revealed systemd security issues, Lennart Poettering argued that these issues aren't a problem because they're resolved on Solaris and will be as soon as Linux gets some additional security mechanism. That sounded to me like systemd would also (theoretically) support Solaris.
Solaris had an init system like systemd for some years, called SMF. It was first released in 2005, the same year Apple released launchd.
It features service dependencies, log collection, fault detection and much more. One of the biggest differences is probably the usage of config files. SMF uses XML files to describe the service and its variables and a program called svcprop to edit variables and create new instances of the service. These can then be managed with svcadm.
It features service dependencies, log collection, fault detection and much more. One of the biggest differences is probably the usage of config files. SMF uses XML files to describe the service and its variables and a program called svcprop to edit variables and create new instances of the service. These can then be managed with svcadm.
I was aware of that, and it wasn't my point. I was talking about the supposed portability of systemd. The question remains, is systemd really Linux-only, or portable to some degree?
I can give a simplified overview of the major difference as I understand it (the difference being the method by which each init system starts its daemons on boot):
sysvinit/bsdinit - Starts daemons in serial (i.e. synchronously). Considered slow and outdated by today's standards.
upstart/launchd - Starts daemons in parallel, based on which daemons depend on each other (If B depends on A, A is started first. If C doesn't depend on anything. C is started at the same time as A. If D depends on C, D is started at the same time as B, and so on).
systemd - Creates all the necessary sockets for each daemon beforehand, and starts nearly all processes in parallel.
Aside from that, they're all configured differently, but if the competition is primarily over speed, systemd wins every time due to its clever design. the newer inits also include a lot of handy tools that aren't part of a traditional init, but that's a different story.
sysvinit/bsdinit - Starts daemons in serial (i.e. synchronously). Considered slow and outdated by today's standards.
upstart/launchd - Starts daemons in parallel, based on which daemons depend on each other (If B depends on A, A is started first. If C doesn't depend on anything. C is started at the same time as A. If D depends on C, D is started at the same time as B, and so on).
systemd - Creates all the necessary sockets for each daemon beforehand, and starts nearly all processes in parallel.
Aside from that, they're all configured differently, but if the competition is primarily over speed, systemd wins every time due to its clever design. the newer inits also include a lot of handy tools that aren't part of a traditional init, but that's a different story.
Ah um some of this is wrong.
upstart doesn't have dependencies thats systemd. Upstart you have to specify when a service should start based on events or combinations of events like "start on started avahi and started nfs". Theoretically this make upstart more flexible though complex event handling is mostly broken. This system also means upstart ends up trying to start everything it can it might start a service which is not needed but because it's start on event has activated it starts. systemd differs in that only required services for that .target are started (and services required by those.
systemd has Require/Wants to specify dependencies as well as the socket activation features. Socket activation requires a compliant daemon as well so a lot of services still use explicit dependencies. Socket activation does give you a lot of other stuff for free, listening on privileged ports as user, restarts without dropping connections, delayed start (not starting until requests come) etc.
upstart doesn't have dependencies thats systemd. Upstart you have to specify when a service should start based on events or combinations of events like "start on started avahi and started nfs". Theoretically this make upstart more flexible though complex event handling is mostly broken. This system also means upstart ends up trying to start everything it can it might start a service which is not needed but because it's start on event has activated it starts. systemd differs in that only required services for that .target are started (and services required by those.
systemd has Require/Wants to specify dependencies as well as the socket activation features. Socket activation requires a compliant daemon as well so a lot of services still use explicit dependencies. Socket activation does give you a lot of other stuff for free, listening on privileged ports as user, restarts without dropping connections, delayed start (not starting until requests come) etc.
Upstart is Ubuntu's event driven alternative to init.d. It's big benefit is that it stands alone, and can mimic init.d for compatibility just fine.
Personally (perhaps being the system I used) I think it's great - very easy to work with, and I've had no stability problems with it whatsoever.
Personally (perhaps being the system I used) I think it's great - very easy to work with, and I've had no stability problems with it whatsoever.
systemd is also sysv and LSB init script compatible.
See the pages for each init system linked to from https://wiki.debian.org/Debate/initsystem
cron's @reboot is very handy
Did Debian at any point consider launchd?
Ubuntu considered using launchd.
https://wiki.ubuntu.com/ReplacementInit?action=show&redirect...
https://wiki.ubuntu.com/ReplacementInit?action=show&redirect...
Doesn't work on Linux.
Launchd works on Linux (and xBSD) -- in the sense, that it can be ported without much effort. Systemd in contrast only works on Linux because it relies heavily on kernel features like cgroups.
The code is shitty and there is no sysvinit script compatibility.
ran across this link, which might be helpful for people familiar sysvinit but not systemd
http://0pointer.de/blog/projects/systemd-for-admins-3.html
tl;dc: systemd replaces the bash scripts you're used to grepping through with unix .conf files that fit on the screen.
http://0pointer.de/blog/projects/systemd-for-admins-3.html
tl;dc: systemd replaces the bash scripts you're used to grepping through with unix .conf files that fit on the screen.
[deleted]
Can an HN mod change the title? The committee has not voted in favor of systemd (yet).
I'm very doubtful as to whether it was within the Technical Committee's role to rule on this. After all, there is nearly a consensus on the fact that systemd is the superior init system. The question of whether certain kernels should have more features by default at the expense of portability is a matter of policy, and not a technical decision.
fucking bureaucrats
I have to remind everyone that the author of systemd is Lennart Poettering, the guy behind Pulseaudio. I think, this is one "feature" that should outweigh all supposed benefits of this program.
For those unfamiliar with Pulseaudio development, it's a third-generation audio subsystem (after OSS and ALSA with JACK forming two previous ones, and ESD being the beginning of the third) that is famous for overcomplicated, non-human-writable barely human-readable configuration procedure, development marred with huge number of bugs that ruined audio on Linux until recently, and suffering from immense number of internal interfaces and system being presented as a huge monolithic piece of software that can not be used in a modular manner except as modules that only talk among themselves.
systemd seems to suffer from the same problems, plus it tries to "integrate" init, udev and syslog into a single "product", with arcane internal interfaces and formats -- just as non-human-writable as Pulseaudio.
For those unfamiliar with Pulseaudio development, it's a third-generation audio subsystem (after OSS and ALSA with JACK forming two previous ones, and ESD being the beginning of the third) that is famous for overcomplicated, non-human-writable barely human-readable configuration procedure, development marred with huge number of bugs that ruined audio on Linux until recently, and suffering from immense number of internal interfaces and system being presented as a huge monolithic piece of software that can not be used in a modular manner except as modules that only talk among themselves.
systemd seems to suffer from the same problems, plus it tries to "integrate" init, udev and syslog into a single "product", with arcane internal interfaces and formats -- just as non-human-writable as Pulseaudio.
So distributions chose to bundle Pulseaudio before it was sufficiently stable, and this is all Lennart's fault and he must forever burn in hell with no way to ever, ever fix or improve things?
The Lennart hate is ridiculous. This time, even Linux kernel hackers think systemd is a good idea. What are your credentials?
The Lennart hate is ridiculous. This time, even Linux kernel hackers think systemd is a good idea. What are your credentials?
Well, when Lennart says that *BSD is irrelevant as if he was the judge of that... I don't see why he shouldn't be able take a little heat. After all - he is the god that wrote, you know, PulseAudio and Systemd.
There are other hackers around that are not "Linux hackers" who might have a different view about the quality of Linux space. I tend to agree with them.
There are other hackers around that are not "Linux hackers" who might have a different view about the quality of Linux space. I tend to agree with them.
What does this suddenly have to do with BSD? kashchei claims that Lennart is incapable of ever producing good code and that all his creations must therefore die. Nothing about BSD.
It may seem unrelated but it is not. Lennart lacks the humility necessary for his contributions to be considered genuine advancements. He dismissed BSD in the context of discussing systemd. The way he put it, anyone who doesn't see the light coming from his code is irrelevant.
When I put this next to the half-success that PulseAudio is (which was similarly promoted and blindly embraced by all major distributions out there), I find questionable the idea of systemd being the next best thing since hot water.
When I put this next to the half-success that PulseAudio is (which was similarly promoted and blindly embraced by all major distributions out there), I find questionable the idea of systemd being the next best thing since hot water.
I do not know if Poettering creates good code. He surely creates successful code, though: Gnome, PulseAudio, Avahi, systemd.
I find hard to read such comments and think that they are valuable contributions anymore.
First of all, Pulseaudio was not the biggest success, true, but can't someone learn from their mistakes? Both are also living, moving software products that continue to improve, as you said, "development marred with huge number of bugs that ruined audio on Linux until recently" - key words: "until recently".
Secondly, about the technical aspects:
http://0pointer.de/blog/projects/the-biggest-myths.html
http://www.freedesktop.org/wiki/Software/systemd/ -> "The systemd for Administrators Blog Series"
Lennard Poettering said it better than I ever will.
First of all, Pulseaudio was not the biggest success, true, but can't someone learn from their mistakes? Both are also living, moving software products that continue to improve, as you said, "development marred with huge number of bugs that ruined audio on Linux until recently" - key words: "until recently".
Secondly, about the technical aspects:
http://0pointer.de/blog/projects/the-biggest-myths.html
http://www.freedesktop.org/wiki/Software/systemd/ -> "The systemd for Administrators Blog Series"
Lennard Poettering said it better than I ever will.
Also: just saying that something is a myth does not make it any less true. The whole point is that systemd (and Pulseaudio) is anti-Unix because its author does not understand Unix design, how would his opinion be of any value in this matter?
I find his arguments quite compelling and honestly, at this stage saying "the author does not understand Unix" just sounds silly.
Judging by his work and his writings, Lennart probably sleeps with a copy of "The Unix Programming Environment" or other such classic under his pillow. He probably knows Unix 10x better than you or me (feel free to point me to your resume/bio if my assumption is wrong :) ).
Just say that you don't agree with his design.
That's fine and it's acceptable. It also turns this debate into something kind of like Linux versus Minix. Working code (his) wins for now ;)
Judging by his work and his writings, Lennart probably sleeps with a copy of "The Unix Programming Environment" or other such classic under his pillow. He probably knows Unix 10x better than you or me (feel free to point me to your resume/bio if my assumption is wrong :) ).
Just say that you don't agree with his design.
That's fine and it's acceptable. It also turns this debate into something kind of like Linux versus Minix. Working code (his) wins for now ;)
The design is still beyond horrible, and on par with Windows. If everything that can be shoehorned into a system and "works" despite being a complicated mess, was accepted, we would have adopted Windows registry and SNMP as primary configuration mechanisms, too -- after all, they both work more reliably than Pulseaudio does.
PA was force-pushed too early, systemd got it's own momentum. AFAIK PA suffered from external unsolvable forces, like hardware/driver giving inconsistent if not false data to PA, causing failures; I believe systemd is shielded from this. The benefits (sound dependency based state) already outbid the other issue one might have with it (less freeform scriptability as in SV).
I see a pattern here. What guarantees that in ten years the same claims won't be made about systemd being pushed in 2014 "while not ready", but by 2023 all issues are ironed out after the whole thing was rewritten three times and was responsible for more security breaches than bind and sendmail combined over their history?
In my opinion, there is no replacement for true modularity, simple, future-proof interfaces, and clear, human-readable and human-writable formats.
In my opinion, there is no replacement for true modularity, simple, future-proof interfaces, and clear, human-readable and human-writable formats.
> I see a pattern here. What guarantees that in ten years the same claims won't be made about systemd being pushed in 2014 "while not ready", but by 2023 all issues are ironed out after the whole thing was rewritten three times and was responsible for more security breaches than bind and sendmail combined over their history?
I've been running systemd as my init system for at least a year. It's also used in Fedora. It is working pretty well by now.
> In my opinion, there is no replacement for true modularity
Systemd is an ecosystem. It contains a number of different binaries. They may be part of the same codebase, but so what?
>, simple, future-proof interfaces, and clear, human-readable and human-writable formats.
You mean, like systemd's unit file format, which is both more readable, and more specified, than the sysvinit boilerplate? If you mean journald, if you have rsyslog as well, you get your usual /var/log/syslog. Best of both worlds.
I've been running systemd as my init system for at least a year. It's also used in Fedora. It is working pretty well by now.
> In my opinion, there is no replacement for true modularity
Systemd is an ecosystem. It contains a number of different binaries. They may be part of the same codebase, but so what?
>, simple, future-proof interfaces, and clear, human-readable and human-writable formats.
You mean, like systemd's unit file format, which is both more readable, and more specified, than the sysvinit boilerplate? If you mean journald, if you have rsyslog as well, you get your usual /var/log/syslog. Best of both worlds.
> Systemd is an ecosystem.
"Ecosystem" == vendor-managed closed system.
True interoperability does not produce "an ecosystem", it produces standards with (at least potentially) multiple implementations.
> It contains a number of different binaries. They may be part of the same codebase, but so what?
So it's contrary to the idea that modularity is achieved through clearly defined interfaces, so "the same codebase" is an unnecessary luxury for lazy designers.
"Ecosystem" == vendor-managed closed system.
True interoperability does not produce "an ecosystem", it produces standards with (at least potentially) multiple implementations.
> It contains a number of different binaries. They may be part of the same codebase, but so what?
So it's contrary to the idea that modularity is achieved through clearly defined interfaces, so "the same codebase" is an unnecessary luxury for lazy designers.
> "Ecosystem" == vendor-managed closed system.
I'm sorry, but you're not making any sense. If a closed system is a project you can fork on github, with ~ 260 contributors and libraries like python-systemd, I don't know how you define "closed".
> So it's contrary to the idea that modularity is achieved through clearly defined interfaces, so "the same codebase" is an unnecessary luxury for lazy designers.
Right. So, the systemd Debian package on my machine has 21 separate binaries. Who in their right mind would want to have 21 separate repositories to keep in sync?
As for "cleanly defined interfaces", I don't know how having several different systems in the same codebase prevents that. Which parts of systemd do you feel are not well-documented and prevents you from writing code to interact with it, or replace part of it?
I'm sorry, but you're not making any sense. If a closed system is a project you can fork on github, with ~ 260 contributors and libraries like python-systemd, I don't know how you define "closed".
> So it's contrary to the idea that modularity is achieved through clearly defined interfaces, so "the same codebase" is an unnecessary luxury for lazy designers.
Right. So, the systemd Debian package on my machine has 21 separate binaries. Who in their right mind would want to have 21 separate repositories to keep in sync?
As for "cleanly defined interfaces", I don't know how having several different systems in the same codebase prevents that. Which parts of systemd do you feel are not well-documented and prevents you from writing code to interact with it, or replace part of it?
systemd is already used and from what I've seen there's far less complaints than PA[1], even talks of admins suggesting to look into it. That's for the 'not ready' part. For the rest, I'd agree with you, but I think the gain in abstraction and correctness is quite worth it, even with it lacks some simplicity.
[1] never encountered a single issue with systemd since archlinux pushed it as default, even on hybrid sysvinit scripts and naked systemd installs, compared to PA which may crash far too regularly, but that's just me.
[1] never encountered a single issue with systemd since archlinux pushed it as default, even on hybrid sysvinit scripts and naked systemd installs, compared to PA which may crash far too regularly, but that's just me.
And yet, it seems to be very popular and is the default audio system in many many Linux distros. It seems odd to me that such a poorly written and obtuse program would be readily embraced by the desktops and distros (and every other program that it needs to interface with).
If the downsides are so severe, it must have some really good upsides, otherwise no one would use it.
My personal anecdote is that Debian installed it for me on my long running system and that I've never touched a config file or otherwise looked at it at all and that my audio always works...
If the downsides are so severe, it must have some really good upsides, otherwise no one would use it.
My personal anecdote is that Debian installed it for me on my long running system and that I've never touched a config file or otherwise looked at it at all and that my audio always works...
I usually just put everything in inittab. ;D
Did anyone see if runit was ever considered? Perhaps it was considered a better alternative to just stick with sysv vs changing to runit?
Now they should start to pray so it will never segfault.)
Since it is vote in a technical discussion, I wouldn't be so sure, until everybody voices their opinion. After all, insight into merits and flaws of each system may change.
And that's what technical (sub)committees are for.
PS I would vote for "further discussion" in a very Debian style.
And that's what technical (sub)committees are for.
PS I would vote for "further discussion" in a very Debian style.
http://aceattorney.sparklin.org/jeu.php?id_proces=57684