LWN: Comments on "McRae: Are We Removing What Defines Arch Linux?"

McRae: Are We Removing What Defines Arch Linux?

philomath — Tue, 28 Aug 2012 18:00:23 +0000

Arch Linux also had systemd for a while now, probably longer. We are talking about making it the default init.

McRae: Are We Removing What Defines Arch Linux?

nix — Sun, 19 Aug 2012 21:55:07 +0000

There's nothing wrong with the nethack source code! (As long as you consider that e.g. modifying string constants is "not wrong"...)

The nethack source is very like nethack itself: an intricate and wonderful maze filled with treasure and surprises and hidden secrets and traps and terrifying monsters of every kind. I actually prefer reading the nethack source to playing nethack. (But perhaps I am strange.)

McRae: Are We Removing What Defines Arch Linux?

anselm — Sun, 19 Aug 2012 20:24:03 +0000

I don't think systemd must support every single hack that is possible in SysV init scripts if it is trivial to do the same thing natively and it works better afterwards, too.

McRae: Are We Removing What Defines Arch Linux?

Eckhart — Sun, 19 Aug 2012 20:19:46 +0000

> Nope. SysV doesn't do anything with dependencies. It's entirely up to script's author to deal with them. It might have been handled in your particular scripts, but it's certainly not universal.

Cortana just wants to point out that there are some hacks in SysV init scripts that are not supported anymore with systemd.
In the given example, several services have been merged into a single init script to overcome the (non-existant) dependency handling of SysV. Systemd isn't able to handle this script properly, since it assumes that starting an already-running service isn't possible.

McRae: Are We Removing What Defines Arch Linux?

mpr22 — Sun, 19 Aug 2012 14:45:49 +0000

That's not a Nethack variant. That's a new roguelike. (Which, for good measure, runs on a rather more restricted set of platforms than Nethack.)

If you want to understand what I'm talking about, read the Nethack source code. Bringing a bottle of brain bleach might be advisable.

McRae: Are We Removing What Defines Arch Linux?

Eckhart — Sun, 19 Aug 2012 14:11:02 +0000

> I know how to write 'exit 0' at the top to temporarily disable them; that's valuable knowledge to me that spans over many variations of unix.

Using 'exit 0' at the top of an init script just shows that you have no clue what you're doing to the service:
- you break the 'status' verb
- you break dependencies between services
- you break manual starting of the service, which is probably not what you want to achieve
You also show that you have no idea what the proper commands (chkconfig foo off / update-rc.d foo disable / …) are.

McRae: Are We Removing What Defines Arch Linux?

cmccabe — Sun, 19 Aug 2012 06:27:26 +0000

SysV init doesn't have support for dependencies. Adding a call to "service restart smbd" in the networking start scripts is a horrible, horrible hack.

If we're going to talk about horrible, horrible hacks, the obvious thing to do is add an smbd sysv init script, and an nmbd sysv init script, and have the one call the other. Meanwhile, if you use systemd, it will just work.

McRae: Are We Removing What Defines Arch Linux?

Kamilion — Sun, 19 Aug 2012 05:05:27 +0000

Heh heh -- there's one way... http://www.wazhack.com/
Developer is committed to Unity4's linux support (when unity4's release occurs)

(Been playing it recently on my android tablet a lot, so in a way, there's already linux support, just not X support.)

McRae: Are We Removing What Defines Arch Linux?

Cyberax — Fri, 17 Aug 2012 20:30:34 +0000

Nope. SysV doesn't do anything with dependencies. It's entirely up to script's author to deal with them. It might have been handled in your particular scripts, but it's certainly not universal.

McRae: Are We Removing What Defines Arch Linux?

cortana — Fri, 17 Aug 2012 19:53:57 +0000

> Why should it?

Because this was the behaviour of the system before systemd is introduced.

> Do it yourself, if you want to use SysV scripts.

I don't want to use SysV scripts. I just want to have a computer that doesn't become inaccessible to other machines on my network when my wireless connection flakes out. I am just pointing out an area where systemd's backwards-compatibility with existing init scripts in the wild is not complete!

McRae: Are We Removing What Defines Arch Linux?

Cyberax — Fri, 17 Aug 2012 19:43:58 +0000

Why should it? Do it yourself, if you want to use SysV scripts.

McRae: Are We Removing What Defines Arch Linux?

cortana — Fri, 17 Aug 2012 19:18:36 +0000

As I tried to describe above, 'systemctl samba.service start' does *not* start nmbd if smbd is still running. It doesn't even try to run the samba init script, because it sees smbd still running and assumes the unit is ok.

McRae: Are We Removing What Defines Arch Linux?

Cyberax — Fri, 17 Aug 2012 16:53:55 +0000

>I don't really see how, without adding a lot of hacks to guess which processes started by an init script should be considered permanent, and which should be considered transient.

Uhm. What's the problem here? All the started processes would be in a single process group which will live on until all of them die. And since you're using SysV emulation it'll be your duty to manage them.

I've just tried to write a simple script that starts two copies of Apache. It works.

McRae: Are We Removing What Defines Arch Linux?

cortana — Fri, 17 Aug 2012 15:50:35 +0000

I went into more detail here: http://lwn.net/Articles/512062/

McRae: Are We Removing What Defines Arch Linux?

cortana — Fri, 17 Aug 2012 15:46:16 +0000

That's just the way Debian's samba init script is written. I was just pointing it out as a specific examine of an instance of impedance mismatch between the real world and systemd's model, in support of dlang's statement that "systemd doesn't satisfy all the functionality of the system it replaces".

McRae: Are We Removing What Defines Arch Linux?

Cyberax — Fri, 17 Aug 2012 15:43:02 +0000

Why they don't work? They should work fine in SysV compat mode.

McRae: Are We Removing What Defines Arch Linux?

mjg59 — Fri, 17 Aug 2012 15:37:34 +0000

http://lists.fedoraproject.org/pipermail/devel/2012-June/... - you can implement this without needing the code in systemd

McRae: Are We Removing What Defines Arch Linux?

mpr22 — Fri, 17 Aug 2012 14:28:33 +0000

Perhaps having tried to develop a Nethack variant has given me a more than usually jaundiced view of what portability involves, but it's pretty obvious to me that cross-OS portability has both benefits and costs, and the relative magnitudes of the two vary wildly depending on what you're trying to do. The costs for an init system are likely to be higher than for a mail system, and it's not at all clear to me that the benefits will be correspondingly higher.

McRae: Are We Removing What Defines Arch Linux?

mpr22 — Fri, 17 Aug 2012 14:17:32 +0000

Is there some very good reason why smbd and nmbd need to be launched by the same script? Because the fix that seems trivially obvious to this armchair general is to have separate smbd.service and nmbd.service units.

McRae: Are We Removing What Defines Arch Linux?

cortana — Fri, 17 Aug 2012 13:58:26 +0000

I don't really see how, without adding a lot of hacks to guess which processes started by an init script should be considered permanent, and which should be considered transient.

The exact example that I'm thinking of was Debian's samba init script, that starts both smbd and nmbd. A bug in nmbd would cause nmbd to exit when my network configuration changed. The bug was fixed by invoking '/etc/init.d/samba start' whenever a network interface came up, however under systemd this was a no-op if smbd was still running, because samba.service was already considered to be 'started'.

McRae: Are We Removing What Defines Arch Linux?

anselm — Fri, 17 Aug 2012 10:36:37 +0000

That sounds fixable to me.

McRae: Are We Removing What Defines Arch Linux?

cortana — Fri, 17 Aug 2012 10:03:02 +0000

Existing SysV init scripts that launch multiple daemons just fine don't work under systemd. Regardless of whether such scripts are a good idea, they exist out there.

McRae: Are We Removing What Defines Arch Linux?

mpr22 — Fri, 17 Aug 2012 09:03:42 +0000

systemd doesn't (and AFAIK won't) support custom verbs in init scripts, so any program which was built on the assumption that you could have custom verbs in init scripts requires additional work to make systemd-friendly.

McRae: Are We Removing What Defines Arch Linux?

anselm — Thu, 16 Aug 2012 23:58:04 +0000

systemd doesn't satisfy all the functionality of the system it replaces.

I was under the impression that systemd can handle existing SysV init scripts (and then some). Is there something in /etc/inittab that systemd doesn't support? I'd be surprised.

McRae: Are We Removing What Defines Arch Linux?

dlang — Thu, 16 Aug 2012 21:39:27 +0000

systemd doesn't satisfy all the functionality of the system it replaces.

nobody is saying that the init process cannot be improved, but "improving" it by adding some things and removing others is highly questionable.

McRae: Are We Removing What Defines Arch Linux?

raven667 — Thu, 16 Aug 2012 21:26:12 +0000

I'm not sure I understand your comment, sysvinit is the one that only addresses the easiest and most popular use cases and has lots of cut corners that make it much less useful than it should be, systemd is the full featured and much more thought through system. sysvinit has no reliable way to shut down a process and the process monitoring and re-spawning feature is mostly unused, barely suitable for local terminals. systemd fixes many of the design elements which were unfinished in sysvinit when it was set in stone in the 80s.

McRae: Are We Removing What Defines Arch Linux?

Zack — Thu, 16 Aug 2012 21:00:50 +0000

Sorry, I forgot to address you last point

>>You don't laugh at Samba for using Linux-specific splice() syscall to accelerate transmission speed, do you?

Of course not.
But Samba runs on a variety of platforms nonetheless. If it wouldn't I would not consider it serious software.

Init is an important subsystem of an operating system. I'm sure it can be redesigned to work faster or in parallel, and I'm glad people are looking into it (even though it's not that important for my use cases). But replacing it with an implementation that addresses just the most popular use cases and ignores the rest is cutting corners. If that implementation presents those cut corners as "features, not bugs", I don't consider it a serious contender for a replacement.

McRae: Are We Removing What Defines Arch Linux?

Zack — Thu, 16 Aug 2012 19:22:36 +0000

>>And that's different from kFreeBSD exactly how?

The FreeBSD kernel maintainers are pretty conservative. I don't think they would apply radical patches or architectural changes readily. So I think it's safe to say their way is different than replacing parts by unfinished software just to see how it works without much forethought.

>>Yes, and hitting CPU with a hammer helps to halt the system. It spans even greater variations.

On most systems one can use
/sbin/init 0
for that. It's something that should work on most unixes (and somewhat comically, happens to be part of the sysvinit package).

>>Simple. It offers real tangible advantages by using features specific to one platform.

And ignores all the other ones. Hence my example of a mail-server. If anyone would propose a new default mailserver for any unix that would be non-portable, the proposal would at best be ignored. But now it's an even more important subsystem for linux, and for some reason it's okay to be sloppy and take shortcuts, viz "The hard parts of programming (like portability) are easy; you just have to leave out the hard parts."

I'm fine with someone trying to do things differently, but as soon as it's pushed as "the one true way", I get wary; especially if there are holes in the approach that are simply being papered over by pronouncing it "sticking to old principles".

McRae: Are We Removing What Defines Arch Linux?

Cyberax — Thu, 16 Aug 2012 18:24:25 +0000

>That would make it a fringe OS, not a toy OS. A toy OS would be an OS where parts of the infrastructure can be replaced by unfinished software or changed just to see how it works out without much forethought.
And that's different from kFreeBSD exactly how?

>What's even better; easy-already-written scripts, on account of them already having been written.
If they are not buggy (and a lot of them are). And

>I know how to write 'exit 0' at the top to temporarily disable them; that's valuable knowledge to me that spans over many variations of unix.
Yes, and hitting CPU with a hammer helps to halt the system. It spans even greater variations.

> If systemd as it was first proposed had been a new mail-daemon, it would have been laughed off the mailinglist. I don't see how it should be judged differently.
Simple. It offers real tangible advantages by using features specific to one platform.

That applies to ANY software, in fact. You don't laugh at Samba for using Linux-specific splice() syscall to accelerate transmission speed, do you?

McRae: Are We Removing What Defines Arch Linux?

Zack — Thu, 16 Aug 2012 17:46:39 +0000

>>it's used by a very small minority

That would make it a fringe OS, not a toy OS. A toy OS would be an OS where parts of the infrastructure can be replaced by unfinished software or changed just to see how it works out without much forethought.

>>easy-to-write unit files

What's even better; easy-already-written scripts, on account of them already having been written. I know how to write 'exit 0' at the top to temporarily disable them; that's valuable knowledge to me that spans over many variations of unix.

If systemd as it was first proposed had been a new mail-daemon, it would have been laughed off the mailinglist. I don't see how it should be judged differently. Or, to paraphrase a well-known joke:

LP's guide to writing portable software:
-step 1: Assume all systems are linux
-step 2 ..

>>Also: automatic dependency-based boot (cool!), reliable service control (über cool), compact and easy-to-write unit files, etc.

Cool as they might be, systemd remains a silver bullet programming in my opinion.
"Linux is not mainstream yet, something's wrong"
"an init system is something"
"Aight, let's rewrite that then"

McRae: Are We Removing What Defines Arch Linux?

Cyberax — Thu, 16 Aug 2012 17:10:36 +0000

Basically, yes. Debian kFreeBSD is a toy OS, it's used by a very small minority (probably hundreds or at most thousands) of Debian users. ZFS is nice, but we've got comparable btrfs which is now quite competitive. And it's as reliable as ZFS (they can both happily chew your files).

> or basically ,"adding racing stripes", makes for a "real operating system" ?
Also: automatic dependency-based boot (cool!), reliable service control (über cool), compact and easy-to-write unit files, etc.

Systemd has tons of very real advantages.

McRae: Are We Removing What Defines Arch Linux?

jubal — Thu, 16 Aug 2012 15:20:06 +0000

Especially that in server environment the boot speed is not a limiting factor; the hardware initialization stage takes way, way longer than booting the system.

And if you take look at the other end of the spectrum; neither android nor chromebooks use systemd and are still able to boot quickly.

McRae: Are We Removing What Defines Arch Linux?

Zack — Thu, 16 Aug 2012 15:02:02 +0000

>>becoz their toy OS port kFreeBSD

So having a familiar GNU userland running on a kernel that is natively capable of ZFS relegates an operating to "toy port" status, whereas

>>performance oriented
>>I cannot deny clear boot speed advantages

or basically ,"adding racing stripes", makes for a "real operating system" ?

There is a group of people for whom systemd is worse than useless, so any "standardization" on it is bound to run into resistance.

McRae: Are We Removing What Defines Arch Linux?

juliank — Thu, 16 Aug 2012 13:24:57 +0000

I guess we should run this script at build-time, and most of the build tools are written in Perl, and a standard Debian chroot for build servers does not have Python installed. Rewriting it in Perl as a debhelper tool would be useful.

McRae: Are We Removing What Defines Arch Linux?

anselm — Thu, 16 Aug 2012 13:06:40 +0000

There is a large number of Debian developers, many of whom may indeed think that supporting kfreebsd is stupid (at least if it holds back the Linux version), and many of whom may not have decided for themselves yet. However, barring a general resolution to the contrary, it only takes a small handful of people who are actively keen on supporting Debian/kfreebsd to keep the thing alive, just like it only takes small handfuls of other people to keep other more or less outlandish software packages in Debian. On the whole this is probably a good thing.

The proper way of handling this, IMHO, is to make systemd the default for Debian on Linux, amend policy to declare systemd unit files mandatory for packages implementing background services on any platform, and provide support for other platforms by adding an automatic method to derive an SysV-style init script (or whatever those platforms need) from a package's systemd unit file if no init script was provided by the maintainers. The GSoC project mentioned elsewhere seems to be a reasonable step in that direction.

McRae: Are We Removing What Defines Arch Linux?

mathstuf — Thu, 16 Aug 2012 12:50:05 +0000

I could see that being worthwhile if an install of Debian didn't already pull in support for the language it was written in, but is it really feasible to make a Python-less system these days?

McRae: Are We Removing What Defines Arch Linux?

mathstuf — Thu, 16 Aug 2012 12:46:43 +0000

I think it's more specifically stated as: "systemd doesn't support FreeBSD because FreeBSD doesn't provide the same features as Linux which systemd depends heavily upon".

McRae: Are We Removing What Defines Arch Linux?

juliank — Thu, 16 Aug 2012 10:44:12 +0000

So, perhaps a rewrite in C or Perl, and we're done.

McRae: Are We Removing What Defines Arch Linux?

Pawlerson — Thu, 16 Aug 2012 07:47:59 +0000

That's the pain, but there's a chance Debian developers will realize supporting kfreebsd is stupid.

McRae: Are We Removing What Defines Arch Linux?

Pawlerson — Thu, 16 Aug 2012 07:46:53 +0000

systemd doesn't support FreeBSD, because it's designed for Linux.