Linked by diegocg on Mon 23rd Aug 2010 14:10 UTC
Linux Lennart Poettering has posted a status update about systemd, an init/upstart alternative. systemd is able now to replace /etc/fstab and cron, and it seems it will be the default init system for Fedora 14. He has also written a post about systemd for administrators.
Thread beginning with comment 437955
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: I am not okay with this
by sorpigal on Tue 24th Aug 2010 14:21 UTC in reply to "RE[3]: I am not okay with this"
Member since:

systemd "fully supports" sysvinit scripts in that it will use them if it must, but it is still the goal of the systemd authors to eradicate such scripts from the boot process.

Support may remain in a technical sense from now until the sun explodes but it will be useless if it is not use d (read: not tested) and not in use (read: I can no longer audit and edit my boot process).

Fact: one goal of systemd is to boot the system without executing shell scripts.

Fact: it is a goal of systemd to eventually get all daemons to stop using init scripts when running on a system using systemd.

I am not okay with either of these things.

You say

Avoiding shell scripts is something a lot of the new init systems do and makes good sense

But I don't see what sense it makes. I see a lot of harm here and no benefit besides some nebulous "well it might be faster." I don't see the question of debugging boot problems addressed at all.

You say
but systemd fully supports sysvinit scripts

But systemd supporters think of this support as an "if you must, if you have something that hasn't been updated yet." What if I don't want to stop using shell scripts? I don't demand sysvinit scripts exactly, but I want non-binary human-readable and -editable.

Just because in 5 years I "can" write a shell script to init sshd, because after all such things are still supported, doesn't mean that any system will ship that way by default, which means that in a failure scenario I will be screwed by default. Unless, of course, I undertake to rewrite all of my system init scripts myself, by hand, and maintain them myself. This is prohibitive.

What is the inherent superiority of hiding boot logic in an impenetrable, unfixable binary? If you say "It's faster" I will laugh--a lot--because sacrificing a little speed for something easy to understand and debug is a no brainer, to me. If it were really worthwhile for speed reasons to do init via small C programs instead of shell scripts why don't we start by replacing all of the things in /etc/init.d/ with C implementations, keeping /sbin/init the same, and see how much people like it.

If it's not a good idea to have C init programs for sysvinit then it's not a good idea for systemd. If it is a good idea then I'd like to hear the justification for why. I know I can write a word or two on the virtue of putting the init logic in shell scripts .

Reply Parent Score: 3

RE[5]: I am not okay with this
by Rahul on Tue 24th Aug 2010 14:31 in reply to "RE[4]: I am not okay with this"
Rahul Member since:

If you want to know why, think beyond just desktop systems. There is Linux now on PDA's, tablets, phones and so on. Executing 99% boiler plate code over and over again doesn't make any sense.

Package maintainers already have written init scripts. They don't have to convert. If they want to take advantage of systemd native service files, they could write one as well but this is hardly going to take any time at all. Here is an actual example

NetworkManager.service file for systemd

Description=Network Manager

ExecStart=/usr/sbin/NetworkManager --no-daemon



The equivalent sysvinit script is:

# NetworkManager: NetworkManager daemon
# chkconfig: - 23 84
# description: This is a daemon for automatically switching network \
# connections to the best available connection.
# processname: NetworkManager
# pidfile: /var/run/NetworkManager/
# Provides: network_manager $network
# Required-Start: messagebus
# Required-Stop: messagebus
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop NetworkManager
# Description: NetworkManager is a tool for easily managing network connections



# Sanity checks.
[ -x $NETWORKMANAGER_BIN ] || exit 1

# Source function library.
. /etc/rc.d/init.d/functions

# Source network configuration
. /etc/sysconfig/network

# so we can rearrange this easily


echo -n $"Setting network parameters... "
sysctl -e -p /etc/sysctl.conf >/dev/null 2>&1

echo -n $"Starting NetworkManager daemon: "
daemon --pidfile $pidfile --check $servicename $processname --pid-file=$pidfile
if [ -n "${NETWORKWAIT}" ]; then
[ -z "${LINKDELAY}" ] && LINKDELAY=10
echo -n $"Waiting for network..."
nm-online -q --timeout=$LINKDELAY || nm-online -q -x --timeout=30
[ "$?" = "0" ] && success "network startup" || failure "network startup"
[ -n "${NETWORKDELAY}" ] && /bin/sleep ${NETWORKDELAY}
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/$servicename

echo -n $"Stopping NetworkManager daemon: "
killproc -p $pidfile $servicename
if [ $RETVAL -eq 0 ]; then
rm -f /var/lock/subsys/$servicename
rm -f $pidfile

# See how we were called.
case "$1" in
status -p $pidfile $processname
if [ -f /var/lock/subsys/$servicename ]; then
echo $"Usage: $0 {start|stop|status|restart|condrestart}"
exit $RETVAL


The difference is enormous. systemd code has extensive support for sysvinit scripts so that it can act as a drop in replacement and it is perfectly fine if most of the system continues to use sysvinit scripts. systemd will support them forever essentially.

Reply Parent Score: 2

sorpigal Member since:

I wrote a reply to this same example on lwn, I won't repeat it here.

If you want to know why, think beyond just desktop systems.

I am thinking specifically of my servers. As for embedded, I understand that there every once of performance matters. Let them over-optimize if they must.

Package maintainers already have written init scripts. They don't have to convert.

Are the systemd developers recommending that sysvinit scripts remain in use and that people do not convert to "native" systemd? If the answer is "No" then sooner or later there will be no more init scripts written at all.

Reply Parent Score: 2