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

Re: /bin/sh (was Re: jessie release goals)

On 05/12/2013 07:40 PM, Helmut Grohne wrote:
With all due respect, this might be utter bullshit, but is at least
[citation needed]. I have yet to see a failing pid 1 (be that sysv,
upstart or systemd). Acquiring data on failure modes of any of those
systems appears like a difficult task and d-devel might not be the best
place to discuss that.

It's not PID 1 itself that is failing, but the daemons and scripts run by the init daemon. The init daemon therefore needs to be more intelligent and provide mechanisms to deal with crashed daemons.

Yes, System V Init has been working for the last three decades. However, we weren't running the very same kernel and plumber land on everything from a smart phone up to a large compute cluster.

systemd provides many useful features that help making systems on any scale more reliable and easier to maintain.

Of course, you don't care if daemon XYZ crashes on your desktop and you're notified immediately, you just reboot in the worst case. However, you *do* care if that happens to the NFS daemon on your home directory server or your httpd on your web server.

You also want to make sure that a single user won't be able to bring down a large login server (systemd's support for cgroups can do that) and you also want remote filesystems always to be mounted reliably when you reboot your system and not being a game of Russian roulette. I have observed both things happen several times on the network of my old university.

I also think it's important to have a proper system of resolving dependencies between daemons in a clean and well-defined, intrinsic way and not through hacky bash scripts where scripts like insserv already fail when my last FAI update created a .prefai_copy file of a script in /etc/init.d.

Socket-based activation is, in my humble opinion, the only proper way to have a proper means of determining dependencies and starting dependency chains of daemons in a reliable, reproducible and atomic way, e.g. either the whole chain runs or not. I don't think you can implement it with the same reliability and elegance using System V Init scripts.

Both Solaris, MacOS X and iOS have dropped the classical System V Init in favor of socket-based activation long time ago and I haven't heard anyone complaining that users got deprived of their choices. The design has proven itself and powers over 100 million iDevices.

The problem is not that people disagree on that a good init system is
needed, but about what good comprises. Some people believe that a good
init system should run on all supported architectures including

Ok, so could you please go ahead and make sure I can use things like launchd, ZFS and jails without any limitations on Linux?

Honestly, you simply can't expect every single package in Debian to run on any of the supported kernels. If systemd profits from the use of Linux-specific kernel features, which is a good thing in my humble opinion because Linux has many very advanced and useful features, it should use them.

I don't understand why these people who are so worried about systemd making the kfreebsd-* ports look bad don't go ahead and port launchd to it. launchd exists and is mature, is largely on feature par with systemd and has been released under a free license. systemd for the Linux ports, launchd for the kfreebsd-* kernels.

By this particular metric sysv init still outperforms
systemd. In fact for every combination of init systems you will find a
metric where one outperforms the other.

No, sysvinit has always been slower for me than systemd. The first thing I do after installing a new Debian box is replacing sysvinit with systemd. It's like using Internet Explorer to download Firefox on Windows.

Let me therefore direct a question to those in favour of a switchable

What are the benefits of using shells other than dash for /bin/sh? (as
opposed to other viable mechanisms to select a shell such as the shebang
of your scripts)

The difference between a shell and an init system is that the former is directly exposed to the user while the latter will only be visible to developers and admins most of the time. It makes sense to be able to customize your user interface, but I don't think it makes sense to be able to customize a core component like the init daemon.

I already think that it's a bit crazy (and geeky) that we have the capability in Debian to choose between different kernels, so I guess it's natural that we have discussions about being able to make choices for init as well :).



 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Reply to: