systemd: Yet Another Init Replacement

lomov_vl · 2010-10-27 02:32:25

Hi again.

I'm continue to use systemd-git, systemd-arch-units and initscript-systemd but now (about a week or so) I have very strange problem: I cannot to boot into Archlinux if I use systemd!

Description:
The boot process begins OK, the / fs is checked some services are started but then I see message that some (/, ...) partitions are mounted in rw regime (this message from /etc/rc.sysinit), then I see the prompt to enter root password or enter Ctrl-D.

Before that, when initscript-systemd provides its own sysinit service I was able to boot my system.

May be some race conditions? Could some one give me a hint how to trace the problem?

EDT: Please ignore my message. I reinstalled initscripts and seems that now I could boot into Archlinux with systemd without problems.

I began use of systemd in earlier days so now my system is messed. The good starting point would be to install a new system and try systemd again but as usually it would be painful.

Last edited by lomov_vl (2010-10-27 12:37:09)

intgr · 2010-10-28 21:40:19

falconindy, I thought a bit about the SSHD_ARGS thing and concluded that adding arguments in /etc/conf.d/sshd file is not a useful feature to begin with. For instance with sshd, options that most users might actually want to change are exposed in sshd_config in a more manageable way; this applies to most daemons these days.

The tiny fraction of users who actually need to add custom arguments can create their own /etc/systemd/system/sshd.service for this purpose.

Now, your patch for better variable expansion (bug #30053) is useful for *some* daemons where the user is expected to pass configuration from the command line -- such as thttpd. But for daemons that don't need this, I would take this opportunity to shed the distro of some legacy baggage. FOO_ARGS used to make sense with rc.d scripts because modifying those is a PITA, but no more with systemd units. Removing this unneeded feature seems more like The Arch Way as well.

In the future, upstreams will start packaging their own unit files too -- and those won't be using including Arch-style /etc/conf.d variables anyway.

What do you think?

mattis · 2010-11-06 15:08:39

Wow, I really like this project. Had some problems with gnome though (sound with pulseaudio not running, shutdown button not showing up...)

I made this unit therefore. No idea if all the After/Requires/etc... are ok. But at least it runs for me right now.

/lib/systemd/system/console-kit-daemon.service

# This file is part of console-kit
#
# console-kit is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# console-kit is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with console-kit; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.

[Unit]
Description=Console Kit Daemon
Requires=dbus.socket
After=syslog.target

[Service]
Type=dbus
BusName=org.freedesktop.ConsoleKit
ExecStart=/usr/sbin/console-kit-daemon --no-daemon
NotifyAccess=main

[Install]
WantedBy=multi-user.target

btw. did anybody get readahead to run?

korpenkraxar · 2010-11-11 09:27:49

So do you guys notice any extra boot speed ompf?

masteryod · 2010-11-17 16:00:53

so how does systemd looks in Arch? will it be default? (when?) is there any speed improvement? is it in harmony with Arch philosophy? and the biggest questions: Is it ultimate replace for init or just another try that will need rewrite soon?

W.F.Cody · 2010-11-21 05:45:35

Has all the weird dependencies of systemd been stripped out yet?
I was thinking a bit about dependency handling during init and apparently, there is a p9p mk-based init system that can handle this decently

http://9fans.net/archive/2009/10/375
https://lug.rose-hulman.edu/svn/misc/trunk/mkinit/

Perhaps it is just me, but moving away from a Bash-dependent init is a good thing (would be nice to have the shell completely optional, but that would require some major legacy porting of bash scripts to generic sh).

Zom · 2010-11-21 10:37:38

W.F.Cody wrote:

Has all the weird dependencies of systemd been stripped out yet?

You tell me.

Only "weird dependency" left is udev-systemd if I understand it correctly.

csn · 2010-11-21 20:11:11

masteryod wrote:

is there any speed improvement?

In general, yes. There's no need for sleep loops anymore and systemd does parallelization wherever possible. For example, my main machine went down to 5-6 seconds compared to 12-13 seconds when booting from GRUB to Xorg+Awesome. But my setup is pretty non-standard, so YMMV. Then again, I didn't tune for speed and I'm also not using systemd's readahead stuff, since I don't care that much about boot times. It's still nice to see, however. (And I wonder what would happen when going from rotating disk to SSD ... ~2 seconds from GRUB to X seems very much possible to me)

masteryod wrote:

is it in harmony with Arch philosophy?

Peronally I see no conflicts there but that ultimately depends on the definition of what PID 1 should do. The traditional definition goes like ``PID 1 is for booting up the system'', and Systemd doesn't fit that definition at all. It is a system manager that also handles initialization because that happens to be a part of system management.

So thinking of systemd as another implementation of init would be misleading in the first place.

The bottom line is that it actually simplifies the whole system. For example, you won't have to deal with multiple different configuration interfaces that are currently involved in managing a system (crond, inetd, etc.). You also get rid of a lot of redundant scripting and so on.

Personally I find it simple to set up and use despite its feature set, even when writing a custom set of unit files from scratch.

masteryod wrote:

and the biggest questions: Is it ultimate replace for init or
just another try that will need rewrite soon?

I can't predict the future but what's clear is that there are at least some key differences between systemd and other/previous attempts at replacing init (Upstart being an exception).

- systemd preserves backwards compatibility to sysv-scripts
- it unifies many aspects of system management/configuration, like (x)inetd, crond, atd, session management and makes them work together (e.g. you can define dependencies between a cron-like timed unit and something else); this makes the whole system more robust, dynamic and whatnot.
- socket based activation alone is a killer feature
- it exploits various features of the linux kernel like cgroups and file system access notifications

I don't intend to hype it, but I think the overall gain is really big and arguably justifies the efforts by distribution developers required to integrate it. As far as I can tell, that has not been the case with previous init systems. The only other project that's like (or would have been like) systemd is Upstart, which unfortunately doesn't seem to take off because development is so slow. Upstart has a very elegant, flexible design while systemd seems to be a more pragmatic approach. But both systems essentially solve the same problems.

Anyway, I think the Arch devs will know when it's the right time to integrate systemd. (IMO they did a very good job at taking this kind of decisions in the past.)

Last edited by csn (2010-11-21 20:13:11)

masteryod · 2010-11-22 10:33:40

thanks csn for your clarification

mattis · 2010-11-24 23:52:38

Concerning speed, some bootup times on a T400s with SSD:
stock kernel:
systemd[1]: Startup finished in 3s 428ms 795us (kernel) + 2s 744ms 611us (userspace) = 6s 173ms 406us.

custom kernel (without initrd):
systemd[1]: Startup finished in 728ms 591us (kernel) + 2s 145ms 838us (userspace) = 2s 874ms 429us.

Gigadoc 2 · 2010-11-29 23:16:12

Hi Guys,
are the systemd-initscripts already worth a try?

Systemd works (almost) fine on my D810, but udev times out. This does not prevent from booting, but it's bothersome to wait…
Someone with the same problem (or even a solution)?

stefano.facchini · 2011-01-02 22:09:09

Hi,
how can I make systemd stop listening to port localhost:631? It seems that this prevents cupsd to access the port, so that I can't configure cupsd via the web interface http://localhost:631

falconindy · 2011-01-02 22:32:10

stefano.facchini wrote:

Hi,
how can I make systemd stop listening to port localhost:631? It seems that this prevents cupsd to access the port, so that I can't configure cupsd via the web interface http://localhost:631

You're misunderstanding. The systemd-arch-units provides a service file for cups that uses socket activation. Whenever a request comes in on port 631, cups starts up, handles the request, and then goes back to sleep.

That said, I'm not sure why a web request doesn't trigger cups to start up. You may need to rewrite the service file to be an always-up deal.

stefano.facchini · 2011-01-02 23:04:35

falconindy wrote:

stefano.facchini wrote:
Hi,
how can I make systemd stop listening to port localhost:631? It seems that this prevents cupsd to access the port, so that I can't configure cupsd via the web interface http://localhost:631
You're misunderstanding. The systemd-arch-units provides a service file for cups that uses socket activation. Whenever a request comes in on port 631, cups starts up, handles the request, and then goes back to sleep.
That said, I'm not sure why a web request doesn't trigger cups to start up. You may need to rewrite the service file to be an always-up deal.

Hi falconindy. Thanks for the explanation, but I am not sure I'm understanding. I have this error in /var/log/cups/error_log:

E [02/Jan/2011:22:18:30 +0100] Unable to bind socket for address ::1:631 - Address already in use.
E [02/Jan/2011:22:18:30 +0100] Unable to bind socket for address 127.0.0.1:631 - Address already in use.

when cupsd starts. Moreover, I get

$ sudo lsof -i:631
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1 root 13u IPv6 6715 0t0 TCP *:ipp (LISTEN)
cupsd 4523 root 3w IPv6 6715 0t0 TCP *:ipp (LISTEN)
cupsd 4523 root 9u IPv4 8144 0t0 UDP *:ipp

Is this a normal output?

Zom · 2011-01-03 05:04:44

stefano.facchini wrote:

Hi falconindy. Thanks for the explanation, but I am not sure I'm understanding. I have this error in /var/log/cups/error_log:
E [02/Jan/2011:22:18:30 +0100] Unable to bind socket for address ::1:631 - Address already in use.
E [02/Jan/2011:22:18:30 +0100] Unable to bind socket for address 127.0.0.1:631 - Address already in use.
when cupsd starts. Moreover, I get
<snip>
Is this a normal output?

How are you starting it?

You shouldn't start it the old sysinit way of '/etc/rc.d/cupsd start'. Rather, you should enable it through systemd with 'systemctl enable cups.service' (IIRC).

Last edited by Zom (2011-01-03 05:05:05)

stefano.facchini · 2011-01-03 10:44:11

Zom wrote:

stefano.facchini wrote:
Hi falconindy. Thanks for the explanation, but I am not sure I'm understanding. I have this error in /var/log/cups/error_log:
E [02/Jan/2011:22:18:30 +0100] Unable to bind socket for address ::1:631 - Address already in use.
E [02/Jan/2011:22:18:30 +0100] Unable to bind socket for address 127.0.0.1:631 - Address already in use.
when cupsd starts. Moreover, I get
<snip>
Is this a normal output?
How are you starting it?
You shouldn't start it the old sysinit way of '/etc/rc.d/cupsd start'. Rather, you should enable it through systemd with 'systemctl enable cups.service' (IIRC).

I solved the problem. When I enabled cupsd, for some weird reason I also enabled cups.socket with "systemctl enable cups.socket", which messed things at startup. Removing cups.socket was the simple solution!

nTia89 · 2011-01-11 20:05:37

hi , i'm new with systemd and i have some questions.

i've installed systemd, arch-units and initscripts from AUR and added an entry in grub with

init=/lib/systemd

.

1- this mean that i can choose between 'standard' boot and 'systemd' boot?

if i select 'systemd' in grub, arch starts faster (only 7s against 15s more or less.....) but now i can't see daemons' output as before

2- how can i restore this?
3- how can i know if all works fine?

and finally the most important two

4- with systemd to start daemon i must use

systemctl start <service>

instead of

/etc/rc.d/<service> start

?
5- daemons in rc.conf are still working?

thanks very much

Last edited by nTia89 (2011-01-11 20:06:44)

falconindy · 2011-01-12 01:31:31

As mentioned by the install scriptlet, you want /bin/systemd, not /lib/systemd.

1) Yes, systemd is carefully packaged to co-exist with sysvinit so you always have a fallback. Just remove the init= parameter from the kernel cmdline or keep a separate bootloader entry.
2) In short, you can't. If you're not using systemd-arch-units and initscripts-systemd-git, then you're not really taking advantage of systemd. Install both those packages and enable the unit files for your daemons as mentioned on installation.
3) systemctl tells you everything you need to know about the various units its aware of. "units" is a general term to describe anything that systemd is cognicent of: daemons, mount points, socket descriptors, temporary directories, runlevels (sort of)...
4) you always need to refer to the unit file by its full name -- mpd is mpd.service. alsa is alsa.service.
5) Currently rc.conf is parsed and systemd starts the daemons it finds in that array, with some amount of respect for dependencies. The underlying mechanics of this will soon change. If you plan on using systemd, do not depend on rc.conf. Please adopt the upstream practice of using the unit files. Again, there's no shortage of them available via the systemd-arch-units package.

patroclo7 · 2011-01-12 11:36:24

Just tried systemd in my system and I have found it difficult to customize.
Among the major problems, four come to mind:
1) I usually perform some important system tasks at boot with /etc/rc.ocal; is there something equivalent?
2) I want more consoles on - say - /dev/tty9 and /dev/tty10; moreover I prefer mingetty over agetty; it seems to me that systemd does not resort to inittab for these tasks; where can I configure the getty implementation I prefer? Moreover at the end of the boot process I am not directly sent to getty, but I have to press enter to go there;
3) I get lots of failure messages for stuff I do not want to use, such as raid; how do I say to systemd not to try to configure raid at all?
4) all the output is garbled and splitted randomly in indented lines of seemingly arbitrary lenghts; is there a place where I can configure the output formatting?

Finally this has been by far the slowest system boot I have ever seen in my system (it usually takes 15 seconds from grub to console, now 42 secons). I have used the systemctl method for all the services for which I have found a *.service file, while resorting to rc.conf for the actually unsupported services.

Last edited by patroclo7 (2011-01-12 11:38:10)

nTia89 · 2011-01-13 15:17:28

thanks for your answer. now

i have a little problem:

when boot, archlinux logo disappers and characters become ginned

and a question:

systemd loads at boot-time all daemons and services, like previous init or load their when i need? i do this question because i notice that kernel loading is faster but in the userspace (after gdm login) it needs much time.....

Last edited by nTia89 (2011-01-13 19:53:43)

tomegun · 2011-01-16 14:03:45

patroclo7 wrote:

Just tried systemd in my system and I have found it difficult to customize.

I'm in the process of updating the documentation, so any questions are highly appreciated.

patroclo7 wrote:

1) I usually perform some important system tasks at boot with /etc/rc.ocal; is there something equivalent?

Both /etc/rc.local and /etc/rc.local.shutdown is supported (there might be some problems in the very short term as I just submitted some patches to deal with this, and they might not have reached you yet).

patroclo7 wrote:

2) I want more consoles on - say - /dev/tty9 and /dev/tty10; moreover I prefer mingetty over agetty; it seems to me that systemd does not resort to inittab for these tasks; where can I configure the getty implementation I prefer?

Have a look at the wiki page. In case it is not clear:
Make two symlinks in /etc/systemd/system/getty.target.wants/ to get getty's on tty9 and tty10.
Copy getty@.service from /lib/systemd/system to /etc/systemd/system and modify it to start mingetty instead of agetty (note: if my memory serves me correctly work is underway to add all the missing functionality to agetty so that mingetty is no longer needed).

patroclo7 wrote:

Moreover at the end of the boot process I am not directly sent to getty, but I have to press enter to go there;

This is interesting. I have never experienced it (but then I'm using graphical.target, so that might explain it). Any more information so we can figure out what goes wrong?

patroclo7 wrote:

3) I get lots of failure messages for stuff I do not want to use, such as raid; how do I say to systemd not to try to configure raid at all?

I'm aware of the raid problem (and just committed a fix), could you please list the other failure messages ('systemctl --full --all | grep fail')?

In order to disable raid, you should be able to do 'systemctl disable md-assemble.service'. Again, this requires the latest version of initscripts-systemd from git, so maybe it has not reached you yet.

patroclo7 wrote:

4) all the output is garbled and splitted randomly in indented lines of seemingly arbitrary lenghts; is there a place where I can configure the output formatting?

This sounds like a bug. If you want less output you can pass 'quiet' to the kernel, or you can customise what output you get using /etc/systemd/system.conf. Beyond that, I'd try to file a bug upstream.

patroclo7 wrote:

Finally this has been by far the slowest system boot I have ever seen in my system (it usually takes 15 seconds from grub to console, now 42 secons). I have used the systemctl method for all the services for which I have found a *.service file, while resorting to rc.conf for the actually unsupported services.

This is definitely a bug (anything slower than sysvinit is a bug). Are you using readahead? If not: try turning it on, reboot a few times and measure the boot speed on the third boot. If you are, try disabling it and compare the boot speed. If none of this gives you a satisfactory boot, could you use bootchart2 and try to get some more information about what goes wrong? To me it sounds like there is a timeout somewhere (udev?).

Let me know if you have more problems or if the wiki page is unclear.

tomegun · 2011-01-16 14:13:06

nTia89 wrote:

when boot, archlinux logo disappers and characters become ginned

I don't know about the Arch logo (maybe this is a bug report for upstream, if you feel strongly about it). However, the font is easy enough. What you are seeing is the default font, the choice of default font is to cover the largest set of characters possible, the downside is that it is butt-ugly (as you have observed). Fix it by setting a nicer font (my recommendation is to install 'terminus-font' and set your font to 'ter-u16n').

The systemd-way of setting your font is 'echo "FONT=ter-u16n" > /etc/vconsloe.conf'. You can also set it in rc.conf as is normal on Arch.

nTia89 wrote:

systemd loads at boot-time all daemons and services, like previous init or load their when i need? i do this question because i notice that kernel loading is faster but in the userspace (after gdm login) it needs much time.....

There are two ways a service is started:
It is "WantedBy" a service or target that is pulled in by your default target. Then it starts on boot like before.
Otherwise, it is dbus or socket activated, and then it starts later (when needed).

It might be benefitial to start services early rather than wait for them to be activated in case you know that they will always be activated. An example of this is console-kit. If you do 'systemctl enable console-kit-daemon.service', then it will be loaded as soon as possible, rather than waiting for gdm to poke it. You can do this to all the services that you think is slowing down your boot by being started late.

Viper_Scull · 2011-01-18 18:04:44

I'd like to give systemd a try. At the moment i'm using kernel 2.6.37-ck from aur with bfs scheduler. Any incompatibility?

I guess wiki article will do for the guidelines.

Now i don't know if it's a silly question, but is it compatible with ureadahead? Is it (ureadahead) recommended for Arch?

falconindy · 2011-01-18 18:08:56

systemd implements its own readahead mechanism, which relies on the fanotify API (which is in 2.6.37).

Last edited by falconindy (2011-01-18 18:09:06)

tomegun · 2011-01-18 18:12:35

@Viper_Scull:
2.6.37-ck should work, but as with any custom kernel, you need to make sure you have the right options enabled when you compile your kernel. The official Arch kernel has the correct options (so if you you Arch's .config you'll be fine). Off the top of my head you need at least cgroups, autofs4, rtc (not as a module), and probably some other (if someone knows a complete list it would be great to have it in the wiki).
ureadahead: never tried this, so I don't know. However, (as it says in the wiki) systemd comes with it's own readahead implementation (I think it is on by default, otherwise the wiki tells you how to enable it).

Arch Linux

#51 2010-10-27 02:32:25

Re: systemd: Yet Another Init Replacement

#52 2010-10-28 21:40:19

Re: systemd: Yet Another Init Replacement

#53 2010-11-06 15:08:39

Re: systemd: Yet Another Init Replacement

#54 2010-11-11 09:27:49

Re: systemd: Yet Another Init Replacement

#55 2010-11-17 16:00:53

Re: systemd: Yet Another Init Replacement

#56 2010-11-21 05:45:35

Re: systemd: Yet Another Init Replacement

#57 2010-11-21 10:37:38

Re: systemd: Yet Another Init Replacement

#58 2010-11-21 20:11:11

Re: systemd: Yet Another Init Replacement

#59 2010-11-22 10:33:40

Re: systemd: Yet Another Init Replacement

#60 2010-11-24 23:52:38

Re: systemd: Yet Another Init Replacement

#61 2010-11-29 23:16:12

Re: systemd: Yet Another Init Replacement

#62 2011-01-02 22:09:09

Re: systemd: Yet Another Init Replacement

#63 2011-01-02 22:32:10

Re: systemd: Yet Another Init Replacement

#64 2011-01-02 23:04:35

Re: systemd: Yet Another Init Replacement

#65 2011-01-03 05:04:44

Re: systemd: Yet Another Init Replacement

#66 2011-01-03 10:44:11

Re: systemd: Yet Another Init Replacement

#67 2011-01-11 20:05:37

Re: systemd: Yet Another Init Replacement

#68 2011-01-12 01:31:31

Re: systemd: Yet Another Init Replacement

#69 2011-01-12 11:36:24

Re: systemd: Yet Another Init Replacement

#70 2011-01-13 15:17:28

Re: systemd: Yet Another Init Replacement

#71 2011-01-16 14:03:45

Re: systemd: Yet Another Init Replacement

#72 2011-01-16 14:13:06

Re: systemd: Yet Another Init Replacement

#73 2011-01-18 18:04:44

Re: systemd: Yet Another Init Replacement

#74 2011-01-18 18:08:56

Re: systemd: Yet Another Init Replacement

#75 2011-01-18 18:12:35

Re: systemd: Yet Another Init Replacement

Board footer