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

Re: administration of initscripts

On 04/15/2013 05:02 AM, Kevin Chadwick wrote:
I have been using Debian for many years now.  In all of that time  I
have never wanted to "manage" init scripts.  I always wonder.  What
are people trying to do?
Hi Bob,

For an example of where one will want to "manage" the init scripts,
take a look at the thread in debian-user with subject "Serveur with
encrypted partition : 2 steps boot." started by erwan@rail.eu.org .
If you are not using a printer, it is also security 101 to disable it's
listening service.

I quite like OpenRC but am currently looking into file-rc, which I would
prefer if direct changes to it were kept but I will have to find the
time to work out how to do that without using commands like update-rc.d
which are not my preference.

I guess I simply prefer the OpenBSD method of an include file that
would override runlevel.conf and may have to look into adding that to
file-rc or a fork at some point.

I lean more towards systemd as I am a desktop Arch user (I use Debian Stable on my server.). Warning, I'm not talkign too much ina Debian context here.

It has a concurrent startup, meaning it brings a system up and down *very* quickly by starting independent units at the same time. Standard SysV init generally cannot do this, though it's hard to account for how initscripts will work, but I've not seen many distributions try and fashion a fully concurrent init system through init scripts. OpenRC allegedly also has concurrent startup, but when using it on Gentoo I've never seen it boot as fast as systemd brings up Arch.

It also has a dependency-based startup. This I've generally seen done in SysV Init. It's nice in systemd though, since you can more finely define what kind of dependencies in unit files there are. This allows the concurrency decide whether to start some units together or sequentially, and in what order. This allows a daemons that must have networking up to have networking up and ready before systemd starts them simultaneously. Combining these two you get daemons started as soon as they can be started and they'll have the environment they need when they start. This is done in all init systems more or less, but systemd tries to get everything going as close to "simultaneously" as it can without breaking daemons. End result: Fast bootup that isn't broken.

Systemd is easy to administrate, more or less. Unit files are declarative, not imperative, meaning you merely have to describe the daemon (In very few terms, no less.) to systemd and systemd will worry about the "how to run" of the daemon you described. The unit files are very small and easy to read/understand/alter.

If you need initscripts, systemd can still handle them, it's as simple as creating a unit file for them. Most systems that use systemd will have a sysvinit-compatible unit or set of units so that systemd shouldn't break your distribution should you switch.

"Runlevels" simply exist as a category of unit files called "targets." It's much easier to set up targets in systemd than having to create custom runlevel scripts that might end up getting ignored by SysV. It's very easy to set these up in systemd.

There are bad parts of systemd:

Systemd has "assimilated" udev, in a manner of speaking. Udev can still run completely without systemd, but for system builders they have to take a lot of extra steps to seperate udev from systemd and install it. Worse, some devs of systemd want to fully integrate udev into systemd and make it so you can't use udev without systemd. This is bad for many distributions as systemd may not be an option. Debian is an example: Debian has a couple pet prijects to be ported to things like HURD and BSD, which do not provide kernel features absolutely necessary for systemd. Some Gentoo developers have forked udev for this reason.

Systemd is not simple on a technical level. Whereas SysV is simply a program that uses simple rules to decide when to execute shell scripts (Whiich is where the complexity and actual functionality of an init is found, ultimately.), systemd is a more complex program that uses simple configuration files to determine how to run everything. This puts a lot of capabilities on systemd instead of on the daemon.

Related to the above two downsides, systemd is not really a crowning example of a developer following the UNIX Philosophy of "one simple task and do it well."

If systemd is not the "official" init system for a distribution, it's a lot more work setting it up to get it working on par with the system's chosen init, as distributors will likely not provide *any* unit files for it. This isn't hard to overcome considering how easy it is to roll a unit file, but still.

Systemd requires a violation of the Filesystem Hierarchy Standard and demands one put /run right in / instead of /var/run. This is really a non-issue and most Linux distributions have wound up gradually moving away from the FHS in some ways to make life easier on their devs.

Administrators might not like systemd's native logger, which outputs solely in a binary form, requiring users to use "journalctl" to read system logs. And you have to run it as root or be part of a special user group to see the ENTIRETY of the journal. This means you might not be able to simply run a LiveCD to read logs to see what went wrong with a system. Fortunately you can use a normal system logger instead.

Some people do *not* like Lennart Poettering, the lead developer, who also gave us "gems" like PulseAudio, which I still cannot stand to this day.

Even with initscripts support, it's still not like SysV init, so deploying systemd takes a bit of a learning curve for *nix veterans, having to unlearn a lot of SysV behavior to understand systemd.

And for Debian: Systemd is not likely to be officially deployed because of its HURD and kFreeBSD projects, which can't use systemd. However, nothing can stop normal Debian users from deploying it themselves, they just might have to work more for it.

Sorry for being wordy.


Reply to: