Comments on: Response to “Why systemd?”

By: Tomasz

Tomasz — 2011年5月02日 21:50:14 +0000

Changing the workflow isn’t necessary a bad thing. Sure, it can be an annoyance. But often specific workflow is a result of working around limtations and bad design decisions in tools. Learning new workflow can let you utilize the power of new tool. Only after you acknowledge that some canonical things can be done different and better you appreciate the new design.

]]>

By: foo

foo — 2011年5月01日 11:21:40 +0000

sysvinit is unreliable in the case of services depending on each other. You have to manually reorder stuff, or automatically reorder stuff based on dependencies encoded in LSB headers. Automatically reordering stuff is hard, especially on custom setups. With systemd that goes away and the kernel does it automatically. Much nicer than sysvinit.

Server boot time matters too.

With sysvinit you lose packets when restarting services, not so with systemd.

]]>

By: oiaohm

oiaohm — 2011年5月01日 03:16:09 +0000

Everyone want to forget the init process itself is a block of C code even with system V. It is in charge of shutting the system down. That init command you run to change run levels under system V sends a message to process 1 on the system. dbus is just a different way and more friendly way todo IPC messages. Interfacing by dbus nothing different really.

“Modular C coded early boot services included.” Did you not read this.
Systemd main source codes include the features todo Mount handling down. But big but these are independent modules. So can be replaced or removed.

Merging in of inetd kinda came a requirement due to how systemd operates.

xinetd/inetd was the first Socket-based Activation system. systemd is the next generation with many improvements so every service can take advantage of xinetd/inetd activation on demand idea even if they are not designed to be xinetd/inetd compatible with systemd. This is why xinetd/inetd cannot mix with systemd. They both will want to be monitoring the same things.

mount handling also falls into mount based Activation. Service has started up it goes to use a partition that is not mounted yet. So systemd suspends it until that is mounted.

The deeper you dig systemd is an Activation based system. Something completely different in a lot of ways to sys v init system. It is basically impossible todo a full activation based system inside the system v model. Also none of the YAIS (Yet Another Init System) ever has been a fully activation based system. Systemd closest living relation is launchd from OS X. Launchd is only partly in the direction of Activation based system.

Activation based system is not an Init system really either. Activation based systems keep on working away after the system has started up.

Encrypted hard disk handling (LUKS) is a good example of this in systemd it handles encrypted harddrives on startup also if you plug them in while the system is running. If harddrive requires password drive may wait until have the machine is booted and dbus sends a message asking for password.

Also due to it being an activation based system not a init based system. It does house keeping on temp directories and the like.

Biggest change is cgroup wrapping of every service so you know what started what. Doing this also would have required a complete rewrite of the shell scripts.

Of course I am not going to say for one moment there are not areas in systemd that cannot be refined. Like possibly making units for mount handling and so on run as independent processes so more tolerant to failures.

Systemd is the first of its kind of system on Linux other than xinetd and inetd. This is important to remember every other init system that has ever been on linux is a rework of the sys v design one way or another. So perfectly fair to call the others YAIS. If systemd is yet another something. Its Yet Another Inetd. Just inetd on serious booster drugs so it can boot the complete system just compatible services. Yes systemd behavior is more like a inetd than a system v init.

A revamp of this size is a chance to fix a lot of historic mistakes and make a few new ones.

]]>

By: Bender

Bender — 2011年4月30日 19:53:21 +0000

Oh yes, we can’t blame sysv very much because it doesn’t do much at all, all we can blame is a badly written script. But the best part in systemd is that it makes it possible to standardize all distros which in many cases modify their scripts etc.

As is the case with hal, systemd uses all best stuff linux has, there is no point in being generic and crappy but work everywhere. Systemd might ease a lot of administration leaving more for proper coding

]]>

By: Michael

Michael — 2011年4月30日 15:43:42 +0000

Well, while sysv work fine since a long time, so would we say about Windows. On a engineering point of view, replacing initscript by something simpler to administer ( systemd unit are cleaner and easier to read/write ) is a big advantage. I remember yelling at the initscripts system because it was so much composed of cut and paste everywhere, because people had varying degree of understanding of the shell scripting, etc. I also often found that having to kill process by hand was rather unsatisfying and fragile.

Maybe systemd do too much. But I think there is a logical reason to unify the boot process like systemd does.

]]>