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.
Order by: Score:
system D looks very promising
by kragil on Mon 23rd Aug 2010 14:54 UTC
kragil
Member since:
2006-01-04

I think SUSE and Debian will adopt it also, but Ubuntu will be a different story. On technical merit alone systemd wins hands down IMO.

Reply Score: 4

RE: system D looks very promising
by cranfordio on Mon 23rd Aug 2010 15:55 UTC in reply to "system D looks very promising"
cranfordio Member since:
2005-11-10

I can't say I know the technical merits, but as I understand it launchd is supposed to do all this and has been open source for years. Isn't this sort of reinventing the wheel? It seems to me that if there is already a system out there for nix based systems to manage all this, shouldn't that be improved upon instead of creating something new? But it may be that these two do different things, I am not sure.

Reply Score: 1

tux68 Member since:
2006-10-24

launchd is supposed to do all this and has been open source for years.


You're right about that. They've said that launchd doesn't fit on Linux very well though, and that it isn't scalable enough. To quote the rather vague explanation:

launchd is a great invention, but I am not convinced that it would fit well into Linux, nor that it is suitable for a system like Linux with its immense scalability and flexibility to numerous purposes and uses.


which you can find in the FAQ section of : http://0pointer.de/blog/projects/systemd.html

Reply Score: 3

Bill Shooter of Bul Member since:
2006-07-14

I think the explanation for that would be similar to this guy's thinking:


http://lowendmac.com/ed/winston/10kw/launchd.html

Reply Score: 3

Rahul Member since:
2005-07-06

Design is very similar to Launchd but the implementation is certainly very different and takes advantage of a lot of Linux specific features like cgroups and SELinux and it has a few extras that launchd didn't have.

Reply Score: 2

RE[2]: system D looks very promising
by uray on Mon 23rd Aug 2010 20:24 UTC in reply to "RE: system D looks very promising"
uray Member since:
2009-08-19

they improving it under different name, and it doesn't mean always reinventing the wheels, even reinventing isn't wrong either. first is sysvinit, then upstart, now systemd. if you give freedom to everyone doing anything under linux this is what happen for its good and bad.

Reply Score: 1

RE: system D looks very promising
by dgjk8734 on Tue 24th Aug 2010 01:21 UTC in reply to "system D looks very promising"
dgjk8734 Member since:
2010-08-24

I also think so.

__________________
[url=http://moviesonlineworld.com]watch free movies online[/url]

Reply Score: 0

systemd is awesome
by Zifre on Mon 23rd Aug 2010 17:36 UTC
Zifre
Member since:
2009-10-04

The more I read about systemd the more I like it. I was initially skeptical, but it seems to be coming along very fast (as opposed to, say, PulseAudio ;) ).

I was actually working on my own init system (which had a similar design to systemd), but now I think I'll just go with systemd. It seems a lot more flexible than the system I was working on, and it looks like all the major distros will be using systemd soon.

Reply Score: 2

RE: systemd is awesome
by Lennie on Mon 23rd Aug 2010 21:38 UTC in reply to "systemd is awesome"
Lennie Member since:
2007-09-22

"it seems to be coming along very fast (as opposed to, say, PulseAudio ;) )"

Then please let him stop developing on systemd, we don't need it that hard and get back to fixing PulseAudio. :-)

Reply Score: 2

RE[2]: systemd is awesome
by Rahul on Mon 23rd Aug 2010 22:30 UTC in reply to "RE: systemd is awesome"
Rahul Member since:
2005-07-06

PulseAudio is a work project and systemd is more of a spare time project. These are both being developed in parallel and unlike PulseAudio which would probably require ongoing work for new features etc, systemd is reaching closer to a bug fix only mode. Unless you are paying someone to do the work, you can't dictate how they spend their time.

Reply Score: 1

RE[3]: systemd is awesome
by mattdm on Wed 25th Aug 2010 18:38 UTC in reply to "RE[2]: systemd is awesome"
mattdm Member since:
2010-08-25

I'm concerned about the claim about it entering "bugfix mode". Just from ideas I've seen from Lennart, there's implementing cron-like behavior and making systemd work for user-level services. There's also some interesting space to explore with cgroups. Without all of this, systemd is less interesting. Add that's not even counting concerns about the current system's complete ability to replace the status quo, or even anything to do with user interaction points and tools. Therefore, if after another month it gets declared done and he moves on, it'd be a shame if other developers don't pick up from there.

Reply Score: 1

RE[4]: systemd is awesome
by Rahul on Wed 25th Aug 2010 18:49 UTC in reply to "RE[3]: systemd is awesome"
Rahul Member since:
2005-07-06

Session support will probably have to come after more wider adoption by other distros besides Fedora. I think in six to 8 months, we wouldn't have much left to do in systemd but I could be wrong about that.

Reply Score: 1

I am not okay with this
by sorpigal on Mon 23rd Aug 2010 20:30 UTC
sorpigal
Member since:
2005-11-02

I am positive on systemd for many reasons, but I am not on board with it for one big one: init scripts. I still see no *need* to kill off init scripts, replacing them as he is with "small C programs," and I see a lot of harm in doing that.

Killing init scripts doesn't make systemd (much) easier or better and it SURE AS HELL makes inspecting what's happening during my boot process harder! What's more, making a small tweak to the init system (at present) from (say) a livecd when the system boot is b0rked is *trivial*. Prevent some services from running? Sure, just delete some symlinks. Modify what happens? Edit the appropriate shell script. Did the script author not anticipate my exact distribution or custom environment? No problem, probably just a simple tweak to the human readable source code.

If you really want to improve bootup speed (and redice your pid count) simply wrap the shell script execution in a single-shell process that has builtins for most of the common tools. This "fixes" 99% of the problems that you supposedly find with init scripts without throwing the baby out with the bathwater.

Still, it's nice to see someone at least *trying* to improve things around here in Linux-land. It's always embarrassing to have to admit that fucking-Windows has better service control.

Reply Score: 4

RE: I am not okay with this
by Rahul on Mon 23rd Aug 2010 21:09 UTC in reply to "I am not okay with this"
Rahul Member since:
2005-07-06

You misread it. If you supply init scripts, systemd will parse and honor it just fine. Systemd's native service files are not init script but very very simple (.desktop style) configuration files but if you somehow want additional flexibility that cannot be done with the service files, feel free to stick with your init scripts and systemd is very compatible with that.

Reply Score: 3

RE[2]: I am not okay with this
by sorpigal on Tue 24th Aug 2010 11:01 UTC in reply to "RE: I am not okay with this"
sorpigal Member since:
2005-11-02

I did not misread it. Go back and read his original announcement for more details, but in the current one he brags about bringing down the number of processes used during boot ("PID now under 500"). When he says this he means "We didn't run shell scripts with lots of utilities" which means "we didn't run shell scripts" which he thinks is a good thing. In one place he says "We reimplemented almost all boot-up and shutdown scripts of the standard Fedora install in much smaller, simpler and faster C utilities, or in systemd itself" - this is part of his crusade against shell scripts as part of the init system.

Here's a fun quote from his "Rethinking PID 1" post:

Another thing we can learn from the MacOS boot-up logic is that shell scripts are evil.

You may not have a problem with it the way I do, but I am not imagining this, it is happening. I don't think Lennart's reasons are very sound, just like I don't think he was right to undermine jackd with PA when a great deal of their problem-set overlaps and could be combined.

It's good that someone is try to solve "whole problems" and not just tiny disconnected pieces (and I applaud that) but some of the choices being made are, in my opinion, just bad.

Reply Score: 3

RE[3]: I am not okay with this
by Rahul on Tue 24th Aug 2010 13:12 UTC in reply to "RE[2]: I am not okay with this"
Rahul Member since:
2005-07-06

Avoiding shell scripts is something a lot of the new init systems do and makes good sense but systemd fully supports sysvinit scripts including several distro extensions for compatibility and will continue to do so. It merely won't be the default. Although offtopic, I would note that jackd developer definitely does not agree with your idea of what overlaps and does not.

Reply Score: 1

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"
sorpigal Member since:
2005-11-02

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 Score: 3

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

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
----------------------------------------

[Unit]
Description=Network Manager
After=syslog.target

[Service]
Type=dbus
BusName=org.freedesktop.NetworkManager
ExecStart=/usr/sbin/NetworkManager --no-daemon

[Install]
WantedBy=network.target multi-user.target
Alias=dbus-org.freedesktop.NetworkManager.service

----

The equivalent sysvinit script is:
-----------------------------------

#!/bin/sh
#
# 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/NetworkManager.pid
#
### BEGIN INIT INFO
# 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
### END INIT INFO

prefix=/usr
exec_prefix=/usr
sbindir=/usr/sbin

NETWORKMANAGER_BIN=${sbindir}/NetworkManager

# 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
processname=NetworkManager
servicename=NetworkManager
pidfile=/var/run/NetworkManager/NetworkManager.pid

RETVAL=0

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

echo -n $"Starting NetworkManager daemon: "
daemon --pidfile $pidfile --check $servicename $processname --pid-file=$pidfile
RETVAL=$?
echo
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"
echo
[ -n "${NETWORKDELAY}" ] && /bin/sleep ${NETWORKDELAY}
fi
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/$servicename
}

stop()
{
echo -n $"Stopping NetworkManager daemon: "
killproc -p $pidfile $servicename
RETVAL=$?
echo
if [ $RETVAL -eq 0 ]; then
rm -f /var/lock/subsys/$servicename
rm -f $pidfile
fi
}

# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
status)
status -p $pidfile $processname
RETVAL=$?
;;
restart)
stop
start
;;
condrestart)
if [ -f /var/lock/subsys/$servicename ]; then
stop
start
fi
;;
*)
echo $"Usage: $0 {start|stop|status|restart|condrestart}"
;;
esac
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 Score: 2

RE[6]: I am not okay with this
by sorpigal on Tue 24th Aug 2010 14:40 UTC in reply to "RE[5]: I am not okay with this"
sorpigal Member since:
2005-11-02

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 Score: 2

RE[7]: I am not okay with this
by Rahul on Tue 24th Aug 2010 14:45 UTC in reply to "RE[6]: I am not okay with this"
Rahul Member since:
2005-07-06

Servers need 99% boiler plate code to be executed? Don't think so. Simple configuration wins. How would you love to have full control over the processes spawned via control groups? How about automatic service recovery? fully detailed reported of why the service failed if it did? And yes, systemd developers are not recommending everyone convert. Even in Fedora 14, only a few default packages ship with native systemd service files and the rest of the system continues to use sysv init scripts. If anyone wants to try it out, they are free to include both. Exclusivity is not needed.

Reply Score: 1

RE[4]: I am not okay with this
by sorpigal on Tue 24th Aug 2010 14:36 UTC in reply to "RE[3]: I am not okay with this"
sorpigal Member since:
2005-11-02

Although offtopic, I would note that jackd developer definitely does not agree with your idea of what overlaps and does not.

Confining OT stuff to another reply.

I didn't say specifically what I thought overlapped (and I won't). People keep saying that the needs of end user and pro audio people are fundamentally different, but when they explain how I am left even more baffled by the disconnect.

It appears that the logic behind PA instead of jack was "Jack is for realtime work, jack is for when you want to process audio first and do everything else second." And therefore a new system was needed. But, then, I read that Lennart wants to 'eventually' add realtime support to PA, and at that point I have to back up and ask: To what extent are these systems solving the same problems? The answer is to a very large extent, even if they are not very similar at the moment they will eventually be quite similar.

If the goal of PA is to eventually do everything jack does, a thing I have heard said, then why didn't we start with jack and work at the goal from the other end? It's NIH, mostly, as far as I can tell. Lots of things that PA does might be useful to jack and the only difference is that for jack it's necessary to provide more tunables and be less conservative. It seems like, in the end, either PA is a special case of jack or jack is a special case of PA, no matter how you look at it this is inevitable.

I've read everything there is to read on this subject, apart from 100% of the codebases of the two projects, and all I see is people working at cross purposes. They're polite about it and will quibble about different goals but the inevitable future is that PA kills jack for all but a few niche scenarios where the PA devs refuse to implement the last 5% of features jack users need and pro audio people are left with a decaying, broken system lacking the man power to sustain itself. You end up with the kind of stupid, fragmented system found on Windows which serves no one especially well.

For the record: I use jack on my systems. I use it for desktop audio. It works very well. Most of the issues are from *inconvenience* due to setup not being automatic (it could be) and problems that PA has, too. (PA has actually made a lot of progress in this area that has helped jack, because due to PA there are fewer and fewer broken apps that don't play nice.) The only remaining issues are (1) Stability, which is a reason to resent PA since work done to stabilize it could be happening on jack, and (2) resource consumption (jack can use a lot.

Reply Score: 2

ANOTHER one?
by ddouthitt on Mon 23rd Aug 2010 23:01 UTC
ddouthitt
Member since:
2010-07-04

One of my pet peeves about UNIX and Linux is that certain areas of UNIX technology only serve to prove the old saying: "I like standards. There are so many to choose from."

Init is one of those. It seems that the standards (Sys V init scripts and BSD rc.* files) are insufficient; so now we have upstart, Solaris SMF, Apple's launchd, simple-init, runinit, and now yet another one: systemd.

I, for one, wonder why everyone hasn't switched to SMF: ZFS has every filesystem guru (and system administrator) swooning, and dtrace makes kernel debugers faint. SMF was the "other" new technology introduced with Solaris 10, and it has to be the most widely used original init system in use today.

So why do we need yet another SysV init replacement?

PS: The thing I miss in most non-SysV init startups? The ability to find out (in realtime even) what subsystem failed to initialize.

Reply Score: 2

RE: ANOTHER one?
by Finalzone on Mon 23rd Aug 2010 23:21 UTC in reply to "ANOTHER one?"
Finalzone Member since:
2005-07-06


I, for one, wonder why everyone hasn't switched to SMF: ZFS has every filesystem guru (and system administrator) swooning, and dtrace makes kernel debugers faint. SMF was the "other" new technology introduced with Solaris 10, and it has to be the most widely used original init system in use today.


Obvious reason: SMF uses CDDL license which is incompatible to GPL.

Reply Score: 2

launchd vs systemd
by Lunitik on Tue 24th Aug 2010 00:55 UTC
Lunitik
Member since:
2005-08-07

Why are people even discussing launchd? It doesn't integrate with almost anything on a Linux system, and would be much more work than what systemd is requiring. If people were fine with that, they'd have just stuck with upstart, but Linux has many mechanisms that simply aren't valid on an Apple system, and upstart is intentionally generic, so by design doesn't take advantage of a lot things systemd will.

If it turns out Lennart is going in the wrong direction, we'll just go to whatever is the next best option at that time, but does launchd even function on a Linux system in the most basic of use cases right now? No, so drop the subject already.

Reply Score: 2