Archlinux is moving to systemd

NotMine · 2012-08-20 04:40:51

Since the forum "tossed" my last post on this topic, let's try again.

"systemd" needs lots of work before it is ready for my world. My world is that of servers, not desktops, so "initscripts" is perfect for me. Past experience with "systemd" on Fedora showed me that "systemd" wasn't ready then. Now I haven't checked to see how much "overhead" is added by running "systemd", but in a server world where "attack surfaces" always have to be considered, any added packages required by "systemd" to get it operational will come under very close scrutiny.

To me Arch boots fast enough now; "systemd" makes no improvement that I care about. I've read some of the comments from the Arch developers and, overall, I like the careful consideration they are giving to the thought of migrating Arch from "initscripts" to "systemd".

To the Arch developers: keep up the good work and thoughtful reflection on this migration. Don't make the mistake that Fedora made moving to "systemd" in Fedora 15 where integration testing and "services support" efforts were "incomplete". Back in the day of Fedora 15 the "systemd" developers completely missed the documentation aspect of their project; no "rosetta stone" documentation to help an "initscripts" user get accustomed to the "systemd" world; the Fedora "man pages" for "systemd" were horrible. I know there is the oft-told joke that developers hate writing documentation, but "systemd" is a radical change for any Linux distribution and not telling the user what all the changes are and how to work with them is just plain inconsiderate of one's end-user community

Last edited by NotMine (2012-08-20 04:47:15)

ngoonee · 2012-08-20 07:38:36

Despite this sob-forum being named 'Arch Discussion', I think I should remind everyone that "Discussions specifically regarding the Arch Linux distribution and community" does not mean "Trying to get decision makers to change their minds about a year too late".

You're welcome to your opinion, and good quality discussion is always enjoyable, but I personally get annoyed with messages with an undertone of "do it this way" and "don't do it this way". The forums are not where decisions are made for Arch.

hoschi · 2012-08-20 07:40:22

I'm just using Archlinux and Fedora on my laptop and desktop, both with a SSD. So I not able to judge this from the point of view of a server administrator. But as mentioned, this should not discussed in this thread

// edit
ngoonee was faster than me.

Last edited by hoschi (2012-08-20 07:41:18)

dolby · 2012-08-20 08:43:14

Hi. Which packages does systemd replace?
I've counted four so far, but im pretty new to this. The ones i know are: initscripts and sysvinit of course, as well as syslog-ng and consolekit. Are there any others im missing?

Last edited by dolby (2012-08-20 08:47:17)

ngoonee · 2012-08-20 08:56:44

dolby wrote:

Hi. Which packages does systemd replace?
I've counted four so far, but im pretty new to this. The ones i know are: initscripts and sysvinit of course, as well as syslog-ng and consolekit. Are there any others im missing?

And your questions are related to the topic... how?

Don't be lazy, go read the documentation that is available. Or try your luck with the IRC. 'Idly wondering' questions have no place here on the technical forums.

dolby · 2012-08-20 09:11:07

Sorry, i will post in another thread.

San2ban · 2012-08-20 10:55:36

on Distrowach

Arch switches to systemd, Damn Small Linux gets resurrected, NetBSD introduces sysupgrade, Mandriva launches foundation, Debian celebrates 19th birthday

Arch Linux As Linux evolves and new technologies take over from established ones, some users are starting to wonder whether these changes are really necessary. It is the turn of Arch Linux, a distribution built on the KISS (Keep It Simple, Stupid) principle that is becoming to experience the pain. But as Allan McRae argues in "Are We Removing What Defines Arch Linux?", the modern innovations are here to be embraced, not shunned: "I think it is plainly obvious that systemd will become the primary system initialization method for Arch Linux in the not-too-distant future (not that this has been formally decided, so take that statement as unofficial). Having not used systemd at all, I really can not comment directly on if it is any good or not. But what do we lose by moving to systemd in Arch? I have seen the following criticisms: Users are being forced to use systemd. This argument really does not hold water. How many initialization systems are currently in use on Arch systems? Just the one currently 'forced' on you." Jason Ryan has more on the same topic in "Trolling Arch Linux".

kokoko3k · 2012-08-20 13:53:15

So, any possible plan about adopting systemd willstay just in the inittialization stage?

I mean, will be possible to just edit a daemon array to make our service starts just as in the past?

WorMzy · 2012-08-20 14:40:22

NotMine wrote:

"systemd" needs lots of work before it is ready for my world. My world is that of servers, not desktops

You use Arch, a "cutting edge" rolling release distro, on servers?

I hope they're not mission critical or anything.

The benefits of systemd don't just stop with faster boot times.

http://0pointer.de/blog/projects/why.html

ANOKNUSA · 2012-08-20 19:50:51

San2ban wrote:

on Distrowach

Arch switches to systemd, Damn Small Linux gets resurrected, NetBSD introduces sysupgrade, Mandriva launches foundation, Debian celebrates 19th birthday

Arch Linux As Linux evolves and new technologies take over from established ones, some users are starting to wonder whether these changes are really necessary. It is the turn of Arch Linux, a distribution built on the KISS (Keep It Simple, Stupid) principle that is becoming to experience the pain. But as Allan McRae argues in "Are We Removing What Defines Arch Linux?", the modern innovations are here to be embraced, not shunned: "I think it is plainly obvious that systemd will become the primary system initialization method for Arch Linux in the not-too-distant future (not that this has been formally decided, so take that statement as unofficial). Having not used systemd at all, I really can not comment directly on if it is any good or not. But what do we lose by moving to systemd in Arch? I have seen the following criticisms: Users are being forced to use systemd. This argument really does not hold water. How many initialization systems are currently in use on Arch systems? Just the one currently 'forced' on you." Jason Ryan has more on the same topic in "Trolling Arch Linux".

I don't see how this adds anything, other than a reminder that Distrowatch.com is not a valid source of official information. Seems a shame that several of these sources quote one of our fine Pacman devs and refer to one of our fine forum mods, and not the stalwart devs actually dealing with this nonsense (the nonsense being the manufactured controversy, that is--not systemd itself). Though both Alan's and Jason's blog posts were good reads, my point is that this Distrowatch quote is just blogspam, and doesn't add anything worthwhile.

@NotMine: Arch is not the most server-friendly distro and wasn't intended to be, so the onus lies with you, not the devs.

MrCode · 2012-08-20 21:23:32

With all the "+1"-style responses I've seen in the mailing list to the proposal, I'm quite frankly surprised there hasn't been an official "Arch is moving to systemd and there's nothing you can do about it" announcement yet… <.<

bwat47 · 2012-08-20 23:55:15

MrCode wrote:

With all the "+1"-style responses I've seen in the mailing list to the proposal, I'm quite frankly surprised there hasn't been an official "Arch is moving to systemd and there's nothing you can do about it" announcement yet… <.<

The way it seems to me is that announcements on the front page generally happen once a change is actually being implemented, currently the devs have only agreed to start the process of switching to systemd in the future. You subscribe to the arch-dev-mailing list for these types of "announcements" (future plans of arch development), and the front page for more urgent news (for example: "arch linux has now switched to systemd as the default init", which hasn't technically happened yet)

Last edited by bwat47 (2012-08-20 23:55:30)

mumpf · 2012-08-21 09:12:48

NotMine wrote:

"systemd" needs lots of work before it is ready for my world.

You generalize your personal experience (for whatever reasons a negative one). Systemd needn't be the cause for that experience.
I have no problems to follow the systemd direction (wouldn't be able anyway to get into the details anyway). However I would appreciate, if the developpers would explain roughly the advantages and explain why the change will be done. Don't get me wrong: allthough the confidence exists, an open communcation including the date of the change etc. is useful. May be a smooth transition (scripts?) could be provided as well.

Last edited by mumpf (2012-08-21 09:50:42)

tomegun · 2012-08-21 13:47:42

mumpf wrote:

However I would appreciate, if the developpers would explain roughly the advantages and explain why the change will be done. Don't get me wrong: allthough the confidence exists, an open communcation including the date of the change etc. is useful. May be a smooth transition (scripts?) could be provided as well.

Timing:

We don't have a date yet, but we have a list of blockers (we need the next releases of util-linux and sysvinit at least, and we need full coverage of systemd service files for all packages that have rc scripts). So I guess the best I can say is "when it is ready". There is also the added wish to do it "as soon as possible" as it will make the packaging of the next versions of certain packages (gnome, polkit at least, but probably many others that I'm not aware of) much easier.

Transition:

We have tried to make this smooth.

0) The best approach is to first bring your rc.conf up-to-date according to the recommendations in "man rc.conf". It should essentially only contain your DAEMONS array (and a few other things, depending on your setup, see manpage for details). This will work both with initscripts and systemd so it is safe to do ahead of time, and make sure everything works as it should.

1) Install systemd, but you do not need to remove initscripts. You can now chose between the two at runtime (by adding init=/bin/systemd to your kernel commandline). If you do this systemd will keep respecting rc.conf and use rc scripts if systemd unit files can not be found.

2) Then you can move your system (hopefully seamlessly) over to a native systemd configuration: do (0) if you did not already, then find the corresponding systemd service file for every daemon in your daemons array and enable it using "systemctl enable <daemon>.service". Once this is done rc.conf is not needed by systemd at all anymore. Go through rc.local and rc.local.shutdown and turn them into service files (or, if you intend to keep them as they are, copy /usr/lib/systemd/system/rc-local{,.shutdown}.service to /etc/systemd/system/).

3) Once the above works ok, and you are confident that you don't need to revert to initscripts, then you can install systemd-sysvcompat, which will conflict (and hence remove) sysvinit+initscripts (and pacsave rc.conf, rc.local and rc.local.shutdown). You can now also remove init=/bin/systemd from your kernel commandline as /sbin/init will now be a symlink to systemd.

Benefits:

I have spent too much time arguing against the perceived deficiencies of systemd (such as: "it is not written in bash", "it was started by Lennart Poettering", "I don't like the (optional) on-disk format of the journal", "it uses dbus", "systemd's PID1 does more and is bigger than sysvinit's PID1", "I think there might be this other project that possibly is doing something similar. I don't really know anything about it, but I'm pretty sure it is better than systemd" and I'm sure there are many more). I strongly believe that 1) all of these perceived deficiencies are not deficiencies, but are actually benefits 2) even if I'm wrong, these things are not hugely important. So, with that out of the way: let's ignore all of those old boring arguments and I'll outline a few things that I find awesome about systemd, and why I think we should all be very excited about soon being able to use it. In no particular order:

0) it is hotplug capable: systemd assumes that all resources may appear and dissapear at any time. If you plug in your external harddrive after systemd has booted, it will be fsck'ed and mounted correctly. This is unlike initscripts which relies on all disks being enumerated and ready when it starts fsck, and then it relies on fsck of all disks being finished before it starts mounting any of them. Hotplug is important, not only because it is convenient to be able to insert/remove hardware while the system is running, but also because that's how the linux kernel does boot: every device appears to be "hotplugged" as the kernel becomes aware of it, so with a very fast boot we can no longer assume that all devices are ready and waiting for us when we need them (even if they were plugged in when the computer started). In reality this is often not a problem, but if you ever had your rootfs on an external USB harddrive you might have experienced problems (and as things become faster and faster more problems like this will crop up).

1) we can know the state of the system: systemd keeps track of all daemons, and all processes that are started, and who owns what, and when something fails, etc. Also, using the (awesome) journal all syslog() entries and writes to stdout/stderr by all processes are captured by systemd. These are stored with enough meta-data so that you can very easily retrieve say "all entries from a certain service/binary/pid" or "all entries written by the kernel regarding a given device", etc. In addition to logging this information, and showing it to you, systemd will allow you to specify (easily) what to do in a wide range of possible error-scenarios: "a service shuts down normally/with an error/ on a signa" or "a service has not sent its watchdog signal in the designated time" or "a service has shutdown with an error 10 times in the last half hour". The recent addition of hardware watchdog support also allows you to say "restart the machine if systemd itself is not responding".

2) it is modular: all of what is now rc.sysinit is split out into many independent services, each of which is well documented and easy to understand. I.e., if you don't like how systemd e.g. does it's fstab handling, then you can write your own little helper (in bash if you wish) to replace the official one. Doing this in the old initscripts is much harder because 1) it is not so clear which parts of rc.sysinit are dependent on eachother 2) any changes you do you'll have to merge on every update.

3) it allows dbus/udev to go back to doing the task they are meant to do: both udev and dbus are currently (mis)-used to start daemons/long-running services on demand. In the case of dbus this is by design, but in the case of udev it is not. Either way, it is not what those daemons were built to do, so in keeping with the UNIX principle of one task per daemon, it is great that we can now let systemd (whose job it is to manage daemons) take this over. That is, udev and dbus can both signal systemd to start a certain daemon, and it will behave like if it was started in any other way (you have the logs, status etc). One problem that this solves is the inherent race-condition in some daemons (I think bluetoothd was guilty of this at some point) allowing both being started as soon as possible on boot (say by putting it in DAEMONS), and to be started on-demand by dbus. Systemd makes sure that both these things can happen, and if they do happen at the same time you will only end up with one instance of the daemon as expected.

4) we can reduce the number of explicit ordering dependencies between daemons (this might require changes to the daemons in question): using socket activation, automounting and dbus activation we are able to forget about stuff like "dbus must be running before we start avahi" or "yp-bind must be started after networkmanager". systemd can create sockets early on, before any daemons are started, and then pass the socket to the relevant daemon when it gets around to starting it. This means that anything can connect to anything else, without caring about whether or not the other daemon has finished starting yet. The kernel will simply buffer the requests whilst we wait and deliver them when it can. Notice that this does not actually remove any dependencies (so if there are circular deps, they will still be there), but it means we no longer have to specify them, nor worry about races between them.

5) we get a lot of security/sandboxing features for free: you can simply add some configuration options to the unit files in question to isolate them from the system in various ways. This was of course also possible before, but it required you to write lots of boilerplate code in every rc script, and this kind of things are very error prone, and best reviewed by people who know about this stuff.

6) systemd service files can (and hopefully will!) be written and distributed upstream: rather than every distro writing their own rc script (with their own set of trivial bugs and misunderstandings) the people who know the software the best (upstream) possibly with some input from the people who know the init system the best (systemd devs) can write "perfect" services that should just work everywhere. We have seen some of this already, and I think it is hugely benefitial. Even for distros who don't pick up systemd yet, this will allow them to at least have an idea oh how the software is meant to be initialized.

7) systemd is a cross-distro project: every major and many, many minor distros have had people contributing to systemd. last i heard even two debian devs have commit access to the repo, among many others. systemd upstream is very accommodating of different needs and different use-cases (as long as they are presented on technical grounds) and have been a pleasure to work with so far. We are getting the joint experience of a lot of people/projects who have worked on different init systems for a long time, I think this is one of the most important "features" one could have.

8) logind will finally deliver on what consolekit was supposed to do: we can now track user sessions and seats, assign permissions to resources on-the-fly etc. This should be the topic of a separate message, as it is too much to get into. Suffice it to say that I'm very happy that we are finally getting these features working as they should.

9) systemd is fast: Or is it really? Some claim there is no difference compared with initscripts, a very few claim it is slower, the vast majority claim it is a lot faster. I claim that I really don't care. The above points (which is just what I could think of at the top of my head, so not exhaustive by any means) would hopefully convince you that systemd is the right choice irrespective of its speed, and once you try it out you might be in for a pleasant surprise ;-)

stryder · 2012-08-21 14:35:03

@tomegun: Great post. Thanks.

mumpf · 2012-08-21 15:23:52

Hi tomegun

Very much appreciated, your detailed comment.

denisfalqueto · 2012-08-22 00:44:16

Thumbs up for Tom! He's doing a superb job as a developer and is very forthcomming. Thank you, man!

scottro · 2012-08-22 01:03:31

I would also like to add my thanks. I suspect it is going to be inevitable and most distributions are going to go that way. Whether that's a good or bad thing, I honestly don't know. So far, it hasn't gotten in my way, but I've only used it in Arch and Fedora on relatively unimportant desktops and laptops, so I'm no more than a casual observer.

Zancarius · 2012-08-22 03:00:04

I'd like to add my thanks to tomegun to the chorus as well. After reading many, many posts from the Arch devs explaining the benefits of systemd and having switched over to it myself, I can say that it is indeed exciting. I realize there will always be those who believe the quip "You can pull initscripts from my cold, dead hands!" but I think as systemd continues to see improvement and refinement, these numbers will dwindle. tomegun's post thoroughly articulates excellent points supporting systemd's adoption (including a large number I didn't know about!).

I'll admit that I was skeptical at first, but after seeing the many benefits systemd has to offer (and experiencing them), I think this has actually been the most significant and important change for all distros to come in many years. I've converted all my systems to systemd because, contrary to what some opinions here have proclaimed, the administrative overhead for me is far lower with systemd. Moreover, if a unit doesn't exist or doesn't do what I want it to, I don't have to worry about tens of lines of bash boilerplate just to get a service working--systemd units really are that much simpler--it's usually just 3-5 lines of easily readable text and that's it. systemd worries about the rest.

From a developer's standpoint, I like systemd better because 1) it's domain knowledge that can be easily ported to other distros that support systemd and 2) it should be trivial to convert a "dumb" application to a fairly basic daemon just by writing a unit file. The other reason it's exciting is because it's really incredible to watch from an outsider's perspective individual developers from around the world who themselves back different distributions working together to achieve a common goal.

I'd like to thank everyone working and contributing to systemd. It's a very impressive thing to watch!

tonythed · 2012-08-22 10:23:07

tomegun wrote:

Benefits:
I have spent too much time arguing against the perceived deficiencies of systemd...

Blah.. blah.. blah.. bottom line is that of your listed 10 bullets.. 95% of your user base does not need or care about any of them. You are taking a set of simple basic functions and turning them into one big interdependent mess of complexity.. definitely not KISS and definitely not in a good direction for any distro. In the past, every time this kind of thing is attempted, where simple is purposely made complex.. what ever the project.. it ends up never completely working right ever, which removes confidence in using the system. I fear this is where arch is headed.. time to bail.

65kid · 2012-08-22 11:07:03

really great post, tomegun! Can't wait for the switch to happen.

tonythed wrote:

Blah.. blah.. blah.. bottom line is that of your listed 10 bullets.. 95% of your user base does not need or care about any of them. You are taking a set of simple basic functions and turning them into one big interdependent mess of complexity.. definitely not KISS and definitely not in a good direction for any distro. In the past, every time this kind of thing is attempted, where simple is purposely made complex.. what ever the project.. it ends up never completely working right ever, which removes confidence in using the system. I fear this is where arch is headed.. time to bail.

Oh no, a user who has no idea what he is talking about wants to switch to another distro! Please don't go, the devs will be devastated!

ebal · 2012-08-22 11:12:17

How i converted to systemd

-- blog link mod-removed by ngoonee - don't do that --

Last edited by ngoonee (2012-08-22 23:36:08)

alphaniner · 2012-08-22 13:15:48

@tomegun

Thank you for the post. As always, your input is enlightening and enjoyable to read.

masteryod · 2012-08-22 13:33:36

My two cents about Arch moving to systemd: Arch devs knows what they're doing, period. Stop whining about KISS/Arch way because many of you obviously don't get it.

My two cents about my experience with systemd: I've done fresh install on my portable USB-HDD, also to check new installation (which was straightforward). I moved to systemd smoothly with no problems at all thanks to our amazingly outstanding wiki. I like very much administrative tools and possibilities of systemd (e.g how easy is to check services status).

PS Only one complain: please, please can we get blue'ish [ OK ] notifications instead of green'ish?

WorMzy · 2012-08-22 14:19:35

masteryod wrote:

PS Only one complain: please, please can we get blue'ish [ OK ] notifications instead of green'ish?

I made a patch for this. If you want to abs it in or vote on the bug report, it's here: https://bugs.archlinux.org/task/31245

Arch Linux

#26 2012-08-20 04:40:51

Re: Archlinux is moving to systemd

#27 2012-08-20 07:38:36

Re: Archlinux is moving to systemd

#28 2012-08-20 07:40:22

Re: Archlinux is moving to systemd

#29 2012-08-20 08:43:14

Re: Archlinux is moving to systemd

#30 2012-08-20 08:56:44

Re: Archlinux is moving to systemd

#31 2012-08-20 09:11:07

Re: Archlinux is moving to systemd

#32 2012-08-20 10:55:36

Re: Archlinux is moving to systemd

#33 2012-08-20 13:53:15

Re: Archlinux is moving to systemd

#34 2012-08-20 14:40:22

Re: Archlinux is moving to systemd

#35 2012-08-20 19:50:51

Re: Archlinux is moving to systemd

#36 2012-08-20 21:23:32

Re: Archlinux is moving to systemd

#37 2012-08-20 23:55:15

Re: Archlinux is moving to systemd

#38 2012-08-21 09:12:48

Re: Archlinux is moving to systemd

#39 2012-08-21 13:47:42

Re: Archlinux is moving to systemd

#40 2012-08-21 14:35:03

Re: Archlinux is moving to systemd

#41 2012-08-21 15:23:52

Re: Archlinux is moving to systemd

#42 2012-08-22 00:44:16

Re: Archlinux is moving to systemd

#43 2012-08-22 01:03:31

Re: Archlinux is moving to systemd

#44 2012-08-22 03:00:04

Re: Archlinux is moving to systemd

#45 2012-08-22 10:23:07

Re: Archlinux is moving to systemd

#46 2012-08-22 11:07:03

Re: Archlinux is moving to systemd

#47 2012-08-22 11:12:17

Re: Archlinux is moving to systemd

#48 2012-08-22 13:15:48

Re: Archlinux is moving to systemd

#49 2012-08-22 13:33:36

Re: Archlinux is moving to systemd

#50 2012-08-22 14:19:35

Re: Archlinux is moving to systemd

Board footer