PDA

View Full Version : Systemd instead of Upstart?



paul_in_london
October 14th, 2010, 12:21 AM
I was reading about systemd recently:

http://www.h-online.com/open/news/item/Systemd-presented-as-SysV-Init-and-Upstart-alternative-991875.html
http://brainstorm.ubuntu.com/idea/24701/
http://lwn.net/Articles/389149/
https://bbs.archlinux.org/viewtopic.php?pid=828523#p828523

Was just wondering if any of you guys have tried it. AFAIK there'll be a package for Debian, but not specifically for Ubuntu:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580814

ranch hand
October 14th, 2010, 01:16 AM
live-config-systemd
"This package contains the systemd backend (experimental!)."
Debian testing repo.

Only entry I can find. Might all still be in the Debian experimental repos. Most stuff there is pretty unstable much more than the Debian unstable repo.

autocrosser
October 14th, 2010, 02:04 AM
Well--I think that Scott R is behind UpStart, so I would guess that systemd would be a very long if ever time coming to Ubuntu......

xebian
October 14th, 2010, 02:04 AM
IIRC Fedora is sticking with upstart for now vs systemd even though systemd is RH development.

seeker5528
October 14th, 2010, 02:14 AM
Was just wondering if any of you guys have tried it. AFAIK there'll be a package for Debian, but not specifically for Ubuntu:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580814

Incentive to try it seems pretty low at this point.

It may be developed from a standpoint of avoiding some of the perceived problems with Upstart and other init systems, but by the time it gets to a point where it does better than Upstart, Upstart will have gotten better as well, so it may never reach a point where it is clearly better than Upstart. But it is good to have competition and, theoretically, developers of each can see elements from the other system that work and make improvements based on those. As long as they and any other alternatives maintain compatibility for sysv/LSB type init scripts for the 3rd party stuff, it shouldn't matter that much which is used within an any given distribution.

Later, Seeker

gnomeuser
October 14th, 2010, 01:59 PM
Systemd is in so many respects far better designed than Upstart in the sense of optimizing for the right use cases and avoiding work.

I would love to see it in Ubuntu but I doubt that will happen as Canonical have spent a small fortune developing Upstart.

I think if this is to happen it will have to be driven by the community which is fine.

The most interesting feature from a user perspective is the boot time enhancements but these require patches to a number of daemons to handle sockets the way systemd expects. While we could likely take these from Fedora, it would still mean replacing a number of core packages with ppa versions during testing.

From an admin pov I think the control group management is far more interesting, this requires the kernel to have the cgroup stuff enabled, I don't know if we do this currently. If not that is another package we would have to change.

I think we can do it, and I would certainly be willing to invest time in such an effort.

What do you say to forming an Ubuntu Systemd team and getting started?

MishaAct
October 14th, 2010, 02:49 PM
I was reading about systemd recently:

http://www.h-online.com/open/news/item/Systemd-presented-as-SysV-Init-and-Upstart-alternative-991875.html
http://brainstorm.ubuntu.com/idea/24701/
http://lwn.net/Articles/389149/
https://bbs.archlinux.org/viewtopic.php?pid=828523#p828523

Was just wondering if any of you guys have tried it. AFAIK there'll be a package for Debian, but not specifically for Ubuntu:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=580814
OMG
That one is pulseaudio and avahi developer
Avahi is ill-designed (reserving .local for internal needs is ever stupid idea), pulseaudio still feels unstable through years.
I wouldn't trust him such an important subsystem.
I would recommend anyone not to use it until it become reliable solution. But I highly doubt it will ))

vishalrao
October 14th, 2010, 02:55 PM
I believe I saw a blueprint for NN titled "finish upstart" - meaning what? complete pending upstart changes - possibly improving boot speed further?

Reiger
October 14th, 2010, 03:53 PM
Systemd is in so many respects far better designed than Upstart in the sense of optimizing for the right use cases and avoiding work.

To some extent. From what I read in the introduction blog post, systemd is inherently a desktop subsystem which does not play well with server type daemons.

It's heart and soul is to start up stuff only when needed, and shut things down aggressively when no longer required. This is perfectly sensible thing to do for a laptop on batteries, but becomes decidedly less fun with services which you might use only occasionally but when you *do* use them you need them to be running *right then*. It's no use having a SSH connection time out over a local network because the SSH daemon is not running, and it's little use either to do a lot of development work on your personal website then intend to do some testing only to find out that Apache 2 is napping -- if nothing is listening connections will fail. And your performance is gone, too.

So for servers or server-type work it looks not that good. It could be the greatest thing since sliced bread but right now it looks more like croissant sopped in French coffee: theoretically the croissant is delicious but I have my doubts about the “soppy” and the “French” parts (lots of milk and not much coffee).

MacUntu
October 14th, 2010, 04:33 PM
With the Upstart author's Apple affinity, I'm not sure if the system's flaws aren't there for a simple reason: to drive users to Mac OS X. Systemd's author on the other hand is also the author of PulseAudio, so its flaws should be more natural w/o any evil motives. I'm all pro systemd.

:lol:


Edit: If you didn't realize that I was just kidding, then please send me a PM so I can put you on my ignore list. #-o

23meg
October 14th, 2010, 04:51 PM
OMG
That one is pulseaudio and avahi developer

Nice ad hominem.


With the Upstart author's Apple affinity, I'm not sure if the system's flaws aren't there for a simple reason: to drive users to Mac OS X. Systemd's author on the other hand is also the author of PulseAudio, so its flaws should be more naturally w/o any evil motives. I'm all pro systemd.

:lol:

Unless you make that smiley four times bigger or use some kind of "kidding" tag, there will soon be people seriously putting those forward as arguments parrot-fashion in favor of switching to systemd all over the web.

MacUntu
October 14th, 2010, 05:01 PM
Fixed, but honestly: can it be more obvious that I was just kidding?

MishaAct
October 14th, 2010, 05:08 PM
Nice ad hominem.
I'm completely ombiassed, but I see only bad-designed projects of this guy. Every time I launch gnome I see avahi's message about .local domain and it can't do anything. On the other hand, I have sound issues at my job after week gnome uptime. They usually being resolved after logout-login. So, it's pure pulseaudio problem.

23meg
October 14th, 2010, 05:10 PM
Fixed, but honestly: can it be more obvious that I was just kidding?

When typing into a vBulletin message box, you can never be too careful.

gnomeuser
October 14th, 2010, 05:59 PM
To some extent. From what I read in the introduction blog post, systemd is inherently a desktop subsystem which does not play well with server type daemons.

It's heart and soul is to start up stuff only when needed, and shut things down aggressively when no longer required. This is perfectly sensible thing to do for a laptop on batteries, but becomes decidedly less fun with services which you might use only occasionally but when you *do* use them you need them to be running *right then*. It's no use having a SSH connection time out over a local network because the SSH daemon is not running, and it's little use either to do a lot of development work on your personal website then intend to do some testing only to find out that Apache 2 is napping -- if nothing is listening connections will fail. And your performance is gone, too.

So for servers or server-type work it looks not that good. It could be the greatest thing since sliced bread but right now it looks more like croissant sopped in French coffee: theoretically the croissant is delicious but I have my doubts about the “soppy” and the “French” parts (lots of milk and not much coffee).


That is true, and those are concerns for which systemd needs to tell a convincing story. Hard but not unsolvable.

With Fedora switching to systemd I would be very surprised if a plan didn't exist to handle these situations. Red Hat tend to be.. fairly dictatorial, when it comes to use cases they care about for RHEL in Fedora and let's face it, they are server people. I doubt they would have agreed to evaluate it for deployment without having considered these problems.

Generally Lennart is good at coming up with elegant solutions for hard problems so I am interested in seeing what his answer is going to be long term. It is clear from certain aspects of Systemd that he does care about administration at least.

That being said, Systemd is still early in development. For Natty I would be happy if we could at least demonstrate it running on Ubuntu.

Starks
October 14th, 2010, 06:17 PM
Considering how long the transition from sysvinit to upstart was, systemd is at least 2 years off.

xebian
October 14th, 2010, 10:50 PM
And Fedora 14 is shipping with the Ubuntu upstart instead of the RH/Fedora systemd. Shows how much faith there is for systemd.

zekopeko
October 14th, 2010, 10:59 PM
And Fedora 14 is shipping with the Ubuntu upstart instead of the RH/Fedora systemd. Shows how much faith there is for systemd.

Systemd is still in its infancy while Upstart was developed during a course of years and is present in Ubuntu from 6.10.

I just hope this doesn't become another Pulseaudio fiasco. Pushing for inclusion in Fedora by default so early doesn't look good to me. So baby steps are preferable here IMO.

23meg
October 14th, 2010, 11:06 PM
And Fedora 14 is shipping with the Ubuntu upstart instead of the RH/Fedora systemd. Shows how much faith there is for systemd.

No, it just shows where systemd stands right now. They fully intend to integrate it in F15.

xebian
October 14th, 2010, 11:11 PM
No, it just shows where systemd stands right now. They fully intend to integrate it in F15.

That was said then for F14. AFAIK early F14 alphas came out with systemd.

23meg
October 14th, 2010, 11:15 PM
That was said then for F14. AFAIK early F14 alphas came out with systemd.

So? If it was postponed to the next release, it means the FESCO and developers responsible still have faith in it; that's what I meant. Lots of feature plans get postponed all the time; it's the nature of the beast.

ssam
October 14th, 2010, 11:56 PM
OMG
That one is pulseaudio and avahi developer
Avahi is ill-designed (reserving .local for internal needs is ever stupid idea)


zeroconf networking is great. avahi seems better than howl (which it replaced). isn't the .local domain part of the zeroconf spec? you can't blame the developer/implementation for following the spec.



pulseaudio still feels unstable through years.


pulseaudio lets you do lots of useful things that could not be done before. it has been stable on all my hardware for years.

though i don't think systemd should be default in ubuntu until it proves its stability and its benefits over upstart. so maybe wait another cycle.

MacUntu
October 15th, 2010, 02:14 PM
So, who's nuts enough to try it? There's also some information on what you need to do before you can use it in another distribution:


Porting systemd To New Distributions

HOWTO:
You need to make the follow changes to adapt systemd to your
distribution:

0) Make your distribution recognized via the autoconf checks
in configure.ac. Grep for the word "fedora" (case
insensitively) and you should be able to find the places where
you need to add/change things.

1) Patch src/hostname-setup.c so that systemd knows where to
read your host name from. You might also want to update
status_welcome() in util.c.

2) Check the unit files in units/ if they match your
distribution. Most likely you will have to make additions to
units/*.m4 and create a copy of units/fedora/ with changes for
your distribution.

3) Adjust Makefile.am to register the unit files you added in
step 2. Also you might need to update the m4 invocation in
Makefile.am. Grep for the word "fedora" (case insensitively)
and you should be able to find the places where you need to
add/change things.

4) Try it out. Play around with 'systemd --test --system' for
a test run of systemd without booting. This will read the unit
files and print the initial transaction it would execute
during boot-up. This will also inform you about ordering loops
and suchlike.

Sounds like a piece of cake. :P:lol::lol:

Nerd_bloke
October 15th, 2010, 03:10 PM
Here's a bit of background on the politics.
Couple of videos from the ubuntudevelopers youtube channel with keybuk (wearing the same fetching shirt) talking about Upstart and drifting onto SystemD:
Maverick UDS Upstart QA:36m30s (http://www.youtube.com/watch?v=ehs2Rl9WSQs#t=36m30s)
Debconf 10 Upstart:36m40s (http://www.youtube.com/watch?v=GNUFA_nK_VM#t=36m40s)

Seems to boil down to other distributions not wanting to loose acknowledgements with Canonical's copyright assignment (http://itmanagement.earthweb.com/osrc/article.php/3904526/Ubuntu-Canonical-Wallow-in-Muddy-Waters-with-Contributors-Agreements.htm), with a bit of "you use Bazaar instead of git" as a figleaf from RedHat.

Shame as PackageKit suffered from NIH too.

zekopeko
October 15th, 2010, 04:03 PM
Shame as PackageKit suffered from NIH too.

What do you mean by this?

Nerd_bloke
October 15th, 2010, 04:48 PM
What do you mean by this?

"not invented here" good practical example is Bug 148084 (https://bugs.launchpad.net/bugs/148084); Fedora have a nice solution in place using PackageKit

zekopeko
October 15th, 2010, 05:23 PM
"not invented here" good practical example is Bug 148084 (https://bugs.launchpad.net/bugs/148084); Fedora have a nice solution in place using PackageKit

Debian and Ubuntu not adopting Packagekit isn't a NIH syndrome but technical deficiencies on the side of Packagekit.

For the past few Ubuntu releases there have been numerous Packagekit related blueprints but they always get deferred because Packagekit doesn't do what Debian and Ubuntu need it to. Why would they replace a good frontend to dpkg with a solution that doesn't cover part of Debian/Ubuntu use cases?

MacUntu
October 15th, 2010, 05:29 PM
Now isn't that cool, with systemd the boot is done after just six seconds!

http://img.xrmb2.net/images/294773.png

:P

gnomeuser
October 15th, 2010, 06:10 PM
Debian and Ubuntu not adopting Packagekit isn't a NIH syndrome but technical deficiencies on the side of Packagekit.

For the past few Ubuntu releases there have been numerous Packagekit related blueprints but they always get deferred because Packagekit doesn't do what Debian and Ubuntu need it to. Why would they replace a good frontend to dpkg with a solution that doesn't cover part of Debian/Ubuntu use cases?

Session API which is part of GNOME and deployed widely. It would be a huge boon.

The effort they put into their PackageKit clone could easily have added the functionality they requested to PackageKit.

Yes that means they would still lack some queuing features but having one standard accepted API would far outweight this deficiency long term.

gnomeuser
October 15th, 2010, 06:11 PM
Now isn't that cool, with systemd the boot is done after just six seconds!

:P

That is pretty nifty, I assume this is without the socket changes still?

MacUntu
October 15th, 2010, 06:26 PM
That is pretty nifty, I assume this is without the socket changes still?
Actually I had no idea what I was doing. Just git cloned the source, made a couple of changes so it would compile, and booted with 'init=/bin/systemd'. :P I really know too little to make this even close to work. I wonder if those '\x2d' in the root partition's UUID are ok.

Reiger
October 15th, 2010, 07:21 PM
The effort they put into their PackageKit clone could easily have added the functionality they requested to PackageKit.

True. Although Packagekit can hardly be considered an adequate replacement for people spoiled with the goodness that is APT/aptitude. It might work better on yum/rpm based systems, but last time (admittedly a long time) I tried it on Fedora it simply appeared to roll over and die on the first massive update thrown its way.

I still do not trust KPackagekit to do anything remotely more complex than a straightforward no-additional-dependencies update, for anything remotely complex I defer to aptitude. That's probably a bit of an unfair knee-jerk response, rooted in a bias from past burns; but as long as KPackagekit lets me apply an update first and only then starts to check whether there are additional dependencies, I am not going to trust it with the health of my OS and it should not be put before people that do not know to run aptitude instead.

MacUntu
October 15th, 2010, 10:32 PM
It's maybe easier to start there (not tried it yet): http://packages.debian.org/experimental/i386/systemd

seeker5528
October 15th, 2010, 11:46 PM
"not invented here" good practical example is Bug 148084 (https://bugs.launchpad.net/bugs/148084); Fedora have a nice solution in place using PackageKit

Considering the codec installer, command not found, etc.. have been in use for quite some time and those are specific use cases where packagekit does well, how is that a practical example?

That's totally different head than using packagekit as the engine for your main package management software. Something it hasn't proved to be good at, judging by the failings of all the KDE/Gnome/GTK package managers that have been created so far.

Later, Seeker

dext
October 16th, 2010, 12:06 AM
And Fedora 14 is shipping with the Ubuntu upstart instead of the RH/Fedora systemd. Shows how much faith there is for systemd.

look at Plymouth, its still a bit young an needs fixing yet even Ubuntu is using it.you can use systemd in F14 but i'd only recommend using it in F14 by advanced users.

Nerd_bloke
October 16th, 2010, 12:36 AM
Considering the codec installer, command not found, etc.. have been in use for quite some time and those are specific use cases where packagekit does well, how is that a practical example?

That's totally different head than using packagekit as the engine for your main package management software. Something it hasn't proved to be good at, judging by the failings of all the KDE/Gnome/GTK package managers that have been created so far.

Later, Seeker

I was just saying that an upstream/cross-distro solution can't be used by Ubuntu... looks like i hit a nerve with a throwaway comment.
Didn't mean to hijack the thread with PackageKit.

Meanwhile no-one even mentions the points raised about SystemD in the video links, which was the reason i posted to begin with.

seeker5528
October 16th, 2010, 01:05 AM
I was just saying that an upstream/cross-distro solution can't be used by Ubuntu... looks like i hit a nerve with a throwaway comment.

If you mean the 'WTF !?!?! Has there been some improvement and commitment from upstream to make it more capable/robust/useful for general package management that I don't know about? What's wrong with just using it for the types of limited use case tools that it seems to be designed for and excels at?' nerve, than I'd say you probably hit it. :P

Later, Seeker

andye
December 21st, 2010, 03:29 PM
This is an old thread now, but in case anyone comes across it...

Unofficial systemd packages for Ubuntu are available here:
https://launchpad.net/~andrew-edmunds/+archive/ppa

For further information, see this wiki page:
https://wiki.ubuntu.com/systemd

MacUntu
December 21st, 2010, 03:49 PM
Thansk for the update. I will definitely give this a try. :)

dino99
December 21st, 2010, 04:03 PM
Thanks for the links and this nice wiki :)

will follow closely this project.