systemd: Yet Another Init Replacement

Kane · 2011-04-22 12:01:12

I've just installed systemd, and have been testing it.

I have to say after reading http://0pointer.de/blog/projects/systemd.html i was expecting a great improvement in performance.

Results:
Standard arch from grub to gdm = 22.40s , 3665 processes, 193Mb memory
Systemd = 23.93s, 3440 processes, 185Mb memory

So yes there is a slight improvement, but for me i cant justify it over the added 'complexity'.

(still having to use daemons array for iptables crond cpufreq and sensors - might this reduce the performance?)

Kane

intgr · 2011-04-22 12:36:22

Kane wrote:

I have to say after reading http://0pointer.de/blog/projects/systemd.html i was expecting a great improvement in performance.

Well, it does take a bit of tweaking to fully exploit its potential.

Did you install initscripts-systemd and systemd-arch-units? Not entirely sure, but without those I think it just runs the usual Arch bash init scripts, so you get no benefits from systemd.

Also, enable systemd-readahead-replay.service and systemd-readahead-collect.service, these will speed up boot the 2nd time around.

To figure out which units are slowing you down, read this: http://0pointer.de/blog/projects/blame-game.html

Kane · 2011-04-22 13:06:48

Did you install initscripts-systemd and systemd-arch-units? Not entirely sure, but without those I think it just runs the usual Arch bash init scripts, so you get no benefits from systemd.
Also, enable systemd-readahead-replay.service and systemd-readahead-collect.service, these will speed up boot the 2nd time around.
To figure out which units are slowing you down, read this: http://0pointer.de/blog/projects/blame-game.html

Thanks intgr,
I had initscripts-systemd and systemd-arch-units installed already however, i just enabled replay and collect and that speeded up the boot by an extra 2.5s

One other slight problem, i tried to get gdm to run using systemctl enable gdm.service, but then upon rebooting it doesnt run. I can only get gdm to work by putting it in the daemons array in rc.conf.

(Edit: if i run systemctl start gdm.service after boot then gdm loads fine, so it seems like its not saving it as enabled?)

Any ideas?

Thanks again
kane

Last edited by Kane (2011-04-22 13:13:47)

falconindy · 2011-04-22 13:50:05

Kane wrote:

(Edit: if i run systemctl start gdm.service after boot then gdm loads fine, so it seems like its not saving it as enabled?)

If you want to start the daemon, you use systemctl start. If you want to enable it, you use systemctl enable.

Kane · 2011-04-22 15:26:44

falconindy wrote:

Kane wrote:
(Edit: if i run systemctl start gdm.service after boot then gdm loads fine, so it seems like its not saving it as enabled?)
If you want to start the daemon, you use systemctl start. If you want to enable it, you use systemctl enable.

I initially tried systemctl enable gdm.service, upon reboot however gdm does not load. So i tried systemctl start gdm.service after boot to test to make sure the gdm.service actually worked correctly (which it does)

Or have i misunderstood the usage? I assumed systemctl enable gdm.service would enable gdm on boot? Or is there something else i have to do?

Cheers
Kane

falconindy · 2011-04-22 15:47:30

Make sure default.target in /lib/systemd/system symlinks to graphical.target. Alternatively, add systemd.target=graphical.target to your kernel cmdline.

Kane · 2011-04-22 15:58:06

lrwxrwxrwx 1 root root 16 Apr 21 03:35 default.target -> graphical.target

I've just tried reinstalling the arch units and initscripts, but no difference.

[root@home kane]# systemctl enable gdm.service
ln -s '/lib/systemd/system/gdm.service' '/etc/systemd/system/graphical.target.wants/gdm.service'

[root@home kane]# ls -l /lib/systemd/system/gdm.service
-rw-r--r-- 1 root root 222 Apr 10 14:38 /lib/systemd/system/gdm.service
[root@home kane]# ls -l /etc/systemd/system/graphical.target.wants/gdm.service
lrwxrwxrwx 1 root root 31 Apr 22 16:56 /etc/systemd/system/graphical.target.wants/gdm.service -> /lib/systemd/system/gdm.service

Does all this look ok?

Edit: Sorry i only just realised, i failed to mention that im using gdm from testing with gnome3, don't know if this needs a different startup script?

Last edited by Kane (2011-04-22 16:20:22)

intgr · 2011-04-22 16:30:10

Kane wrote:

lrwxrwxrwx 1 root root 16 Apr 21 03:35 default.target -> graphical.target
I've just tried reinstalling the arch units and initscripts, but no difference.

You have to delete the /etc/systemd/system/default.target file, then it will choose graphical.target by default. /etc/systemd/ files always override what's in /lib/systemd/.

This has always annoyed me. By default the /etc/inittab file defaults to runlevel 3, so the systemd post_install script tries to be uber-smart and creates a default.target pointing to it. I'd much prefer that it didn't do this magic.

  # Try to read default runlevel from the old inittab if it exists
  runlevel=$(/bin/awk -F':' '$3 == "initdefault" && $1 !~ "^#" { print $2 }' /etc/inittab 2> /dev/null)
  if [ -z "$runlevel" ]; then
    target="/lib/systemd/system/graphical.target"
  else
    target="/lib/systemd/system/runlevel$runlevel.target"
  fi

  # And symlink what we found to the new-style default.target
  /bin/ln -sf "$target" /etc/systemd/system/default.target

Kane wrote:

Edit: Sorry i only just realised, i failed to mention that im using gdm from testing with gnome3, don't know if this needs a different startup script?

No, that makes no difference.

Last edited by intgr (2011-04-22 16:38:07)

falconindy · 2011-04-22 19:07:17

intgr wrote:

This has always annoyed me. By default the /etc/inittab file defaults to runlevel 3, so the systemd post_install script tries to be uber-smart and creates a default.target pointing to it. I'd much prefer that it didn't do this magic.

Looking at the structure of the installed package, this actually isn't necessary any longer. default.target defaults to graphical. If you never enable a DM on installation, this will silently fall back to tty. I'll remove it for the next release.

falconindy · 2011-04-22 19:31:29

I'm officially (as officially as I can) deprecating initscripts-systemd. What does this mean?

arch-persistent-settings.service and rc-local.service will move to community/systemd.
lvm.service is moving to community/systemd-arch-units.
arch-daemon is going away. It's a kludge and I don't like it.

When is this happening? Not sure yet. Probably sooner rather than later. It's too much for me to maintain, particularly when I've been able to pare down the initscripts package to 6 files with plans to remove 2 of them. Figure less than a month.

Last edited by falconindy (2011-04-22 19:32:37)

Kane · 2011-04-22 20:33:43

sorry me again guys,

Looks like i've completely fubar'ed it now.

I removed everything (this is before reading intgr's reply)

Pacman -Rsc systemd

However this still left /etc/systemd/ directory, so i removed this and all the .service and .wants within it.

So then i thought id try reinstalling it from scratch:

pacman -S initscripts-systemd

Which also installed systemd, however when systemd is installing i get this message:

warning: directory permissions differ on run/
filesystem: 1777 package: 755

(Don't remember seeing it when i first installed it)

I then installed systemd-arch-units

Rebooted (with init=/bin/systemd appended to kernel line in grub)

(This is the same installation method i used to begin with when it worked)

Now when i try and boot using systemd it stops at the line:

Started remount root FS

For about 5 minutes, and then afterwards prints alot of red aborted errors.

Starting Getty on tty5 aborted because a dependency failed

However i can't scroll up to find out what this dependency was.

Anyone any ideas why this might have suddenly stopped working?

Cheers
Kane

vinhsynd · 2011-04-23 03:39:08

Hi!

I read through the wiki and have been looking to try out systemd, however I couldn't find anything on using it with a LUKS encrypted root partition. Has anyone tried this out already?

MurdersLastCrow · 2011-04-23 05:41:36

Oddly enough, while you guys are reporting relatively insignificant changes in boot speed, my boot went from 23 seconds to 10 just from systemd's basic setup. I'm not even using readahead, yet. So I'd say this is the next big thing, and hopefully we can continue to improve on it to get our boot times down to something miniscule and insignificant.

My phone starts much slower than my computer now. Not sure if that's a good thing. XD

eworm · 2011-04-23 06:53:53

vinhsynd wrote:

I read through the wiki and have been looking to try out systemd, however I couldn't find anything on using it with a LUKS encrypted root partition. Has anyone tried this out already?

Yes, I did, working on a luks encrypted system with systemd atm.
As the initrd manages the root filesystem decryption systemd does not have to care at all... Just try it out, works without problems!

pankajmore · 2011-04-23 12:51:15

How do i set auto login using systemd ,

I had mingetty --autologin username in /etc/inittab to login to a virtual console. Since sytemd doesnt use inittab ,
I tried replacing the getty file at /etc/systemd/system... to use mingetty but it didnt boot

ejona86 · 2011-04-23 13:14:09

I was in the same state as Kane, with gdm never starting. As I remember, /etc/systemd/system/default.target pointed to graphical.target, but gdm still wouldn't start on bootup (and it was enabled via systemctl enable). I ended up deleting /etc's default.target and I think a few other files in /etc/systemd and now gdm starts correctly. Just as a note, I had systemd installed much earlier (back when it was in AUR and we were required to use the -git version) and had very little problem with it then, but I didn't have the time to verify the system was correct so I didn't swap over to using it permanently.

I am not seeing my DAEMONS start up though. That seems like a arch-daemon.service problem, but I am seeing it generate things in /run/systemd/generator. As a workaround, I have thus have gone through the list of DAEMONS and manually enabled any of the services I can, but it seems that any service that doesn't have a native .service file can't be enabled:

[root@Twin ~]# systemctl status samba.service
samba.service
      Loaded: loaded (/etc/rc.d/samba)
      Active: inactive (dead)
      CGroup: name=systemd:/system/samba.service
[root@Twin ~]# systemctl enable samba.service
Couldn't find samba.service.
[root@Twin ~]# systemctl is-enabled samba.service
Couldn't find samba.service.
[root@Twin ~]# systemctl start samba.service
[root@Twin ~]# systemctl status samba.service
samba.service
      Loaded: loaded (/etc/rc.d/samba)
      Active: active (running)
     Process: 4676 ExecStart=/etc/rc.d/samba start (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/samba.service
          ├ 4687 /usr/sbin/smbd -D
          ├ 4690 /usr/sbin/nmbd -D
          └ 4691 /usr/sbin/smbd -D

I don't understand how systemd lets me start start something manually, but not allow me to enable it to be started automatically. It really seems like arch-daemons.service isn't contributing anything because there is a samba.service in /run/systemd/generator/arch-daemons.target.wants/.

Just as a side question, since arch-daemon.service (and thus DAEMONS support) is going away, then new users will need to 'systemctl enable' all the things in the DAEMONS list?

falconindy · 2011-04-23 13:41:44

ejona86 wrote:

I was in the same state as Kane, with gdm never starting. As I remember, /etc/systemd/system/default.target pointed to graphical.target, but gdm still wouldn't start on bootup (and it was enabled via systemctl enable). I ended up deleting /etc's default.target and I think a few other files in /etc/systemd and now gdm starts correctly. Just as a note, I had systemd installed much earlier (back when it was in AUR and we were required to use the -git version) and had very little problem with it then, but I didn't have the time to verify the system was correct so I didn't swap over to using it permanently.
I am not seeing my DAEMONS start up though. That seems like a arch-daemon.service problem, but I am seeing it generate things in /run/systemd/generator. As a workaround, I have thus have gone through the list of DAEMONS and manually enabled any of the services I can, but it seems that any service that doesn't have a native .service file can't be enabled:
[root@Twin ~]# systemctl status samba.service
samba.service
      Loaded: loaded (/etc/rc.d/samba)
      Active: inactive (dead)
      CGroup: name=systemd:/system/samba.service
[root@Twin ~]# systemctl enable samba.service
Couldn't find samba.service.
[root@Twin ~]# systemctl is-enabled samba.service
Couldn't find samba.service.
[root@Twin ~]# systemctl start samba.service
[root@Twin ~]# systemctl status samba.service
samba.service
      Loaded: loaded (/etc/rc.d/samba)
      Active: active (running)
     Process: 4676 ExecStart=/etc/rc.d/samba start (code=exited, status=0/SUCCESS)
      CGroup: name=systemd:/system/samba.service
          ├ 4687 /usr/sbin/smbd -D
          ├ 4690 /usr/sbin/nmbd -D
          └ 4691 /usr/sbin/smbd -D
I don't understand how systemd lets me start start something manually, but not allow me to enable it to be started automatically. It really seems like arch-daemons.service isn't contributing anything because there is a samba.service in /run/systemd/generator/arch-daemons.target.wants/.
Just as a side question, since arch-daemon.service (and thus DAEMONS support) is going away, then new users will need to 'systemctl enable' all the things in the DAEMONS list?

The point of generators is that they're dynamic. You can't rely on something dynamic existing on next boot so units created by a generator are, by design, unable to be enabled. We've amassed a large amount of units in systemd-arch-units, and anything that still needs to be kludged along in lieu of a proper native unit can be created as simply as the generated units in /run/systemd/generator/arch-daemons.target.wants/.

So, to answer your question: no. It won't have to be done because it can't be done. This is part of why arch-daemons needs to go away. Contrary to popular belief, systemd isn't about booting in 6 seconds, but using native unit files instead of wrappers around shell scripts certainly helps. The fact that this was enabled by default means that things just magically work on bootup and no one thinks twice because it just works™. While it is rather convenient, it's stifling to my efforts of integration because we're not seeing native service files created for popular services.

edit: and here's a samba unit file, because I notice that systemd is not able to correctly determine the PID of smbd.

[Unit]
Description=Samba/NetBIOS Services

[Service]
ExecStart=/usr/sbin/smbd -F
ExecStart=/usr/sbin/nmbd -F

[Install]
WantedBy=multi-user.target

Last edited by falconindy (2011-04-23 13:50:28)

pankajmore · 2011-04-23 14:14:19

on boot i get this

<30>systemd-fsck[772]: /dev/sda1: clean, 400835/2501856 files, 3939069/10000454 blocks
<30>systemd-fsck[2424]: /dev/sda4: Superblock last write time is in the future.
<30>systemd-fsck[2424]: (by less than a day, probably due to the hardware clock being incorrectly set). FIXED.
<30>systemd-fsck[2424]: /dev/sda4: clean, 717737/26402816 files, 68396908/105595245 blocks
<30>systemd-fsck[2428]: Reiserfs super block in block 16 on 0x802 of format 3.6 with standard journal
<30>systemd-fsck[2428]: Blocks (total/free): 5000224/1279347 by 4096 bytes
<30>systemd-fsck[2428]: Filesystem is clean

time changes at each boot , any idea how to fix it .... I am using UTC and no windows

igndenok · 2011-04-23 14:28:46

According to systemctl man

poweroff
    Shut down and power-off the system. This is mostly equivalent to start poweroff.target but also prints a wall message to all users.
    If combined with --force shutdown of all running services is skipped, however all processes are killed and
    all file systems are unmounted or mounted read-only, immediately followed by the powering off.

If I using 'systemctl poweroff' my system on immediately a few ms after off, but not with 'systemctl start poweroff.target'.
Is that by design or what ?!

falconindy · 2011-04-23 14:32:11

You generally don't want to 'start' targets, you isolate them.

igndenok · 2011-04-23 15:32:28

Ah, I see. My bad for not read man further, and just a while ago I got error because it couldn't detect vfat filesystem.
After reboot it, the error was gone

lymphatik · 2011-04-24 09:07:36

I tried this for laptop-mode service but it seems that it does not stay active. Should I add something like this RemainAfterExit=yes

[Unit]
Description=Laptop power saving package
After=syslog.target acpid.service
Wants=acpid.service

[Service]
ExecStart=/usr/sbin/laptop_mode auto
ExecStop=/usr/sbin/laptop_mode stop

[Install]
WantedBy=multi-user.target

And I tried the code from gentoo for lighttpd and it seems to work flawlessly

[Unit]
Description=Lighttpd Daemon
After=network.target

[Service]
ExecStartPre=/usr/sbin/lighttpd -t -f /etc/lighttpd/lighttpd.conf
ExecStart=/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

/etc/tmpfiles.d/lighttpd.conf

d /var/run/lighttpd 0750 http http -

http://en.gentoo-wiki.com/wiki/Systemd

Last edited by lymphatik (2011-04-24 09:35:29)

unikum · 2011-04-24 09:48:26

/usr/sbin/laptop_mode not contain 'stop' option. See man page.

Last edited by unikum (2011-04-24 09:50:00)

Zom · 2011-04-24 10:27:33

lymphatik wrote:

I tried this for laptop-mode service but it seems that it does not stay active. Should I add something like this RemainAfterExit=yes
[Unit]
Description=Laptop power saving package
After=syslog.target acpid.service
Wants=acpid.service

[Service]
ExecStart=/usr/sbin/laptop_mode auto
ExecStop=/usr/sbin/laptop_mode stop

[Install]
WantedBy=multi-user.target

I did something similar, but used the scripts in /etc/rc.d/ instead (Yeah, I'm terribly lazy sometimes), and I don't have a daemon running either. I think it simply doesn't have a daemon, that it just sets the values from the config file to something in the kernel. Maybe.

lymphatik · 2011-04-24 13:28:18

Well from the rc.d

[ ! -d /var/run/laptop-mode-tools ] && install -d /var/run/laptop-mode-tools
    touch /var/run/laptop-mode-tools/enabled
    /usr/sbin/laptop_mode auto >/dev/null 2>&1

It seems you have to create a directory and file to activate it. But I have no idea how to do that for the moment. Maybe with tmpfile.d. Will and comeback to you if I find something interesting.

Edit
/etc/tmpfiles.d/laptop-mode.conf

d /var/run/laptop-mode-tools 0755 root root
f /var/run/laptop-mode-tools/enabled 0644 root root

But this actually activate laptop-mode all the time you cannot stop it. I have not found yet how to delete files when a execstop is launched.

Last edited by lymphatik (2011-04-24 13:55:51)

Arch Linux

#426 2011-04-22 12:01:12

Re: systemd: Yet Another Init Replacement

#427 2011-04-22 12:36:22

Re: systemd: Yet Another Init Replacement

#428 2011-04-22 13:06:48

Re: systemd: Yet Another Init Replacement

#429 2011-04-22 13:50:05

Re: systemd: Yet Another Init Replacement

#430 2011-04-22 15:26:44

Re: systemd: Yet Another Init Replacement

#431 2011-04-22 15:47:30

Re: systemd: Yet Another Init Replacement

#432 2011-04-22 15:58:06

Re: systemd: Yet Another Init Replacement

#433 2011-04-22 16:30:10

Re: systemd: Yet Another Init Replacement

#434 2011-04-22 19:07:17

Re: systemd: Yet Another Init Replacement

#435 2011-04-22 19:31:29

Re: systemd: Yet Another Init Replacement

#436 2011-04-22 20:33:43

Re: systemd: Yet Another Init Replacement

#437 2011-04-23 03:39:08

Re: systemd: Yet Another Init Replacement

#438 2011-04-23 05:41:36

Re: systemd: Yet Another Init Replacement

#439 2011-04-23 06:53:53

Re: systemd: Yet Another Init Replacement

#440 2011-04-23 12:51:15

Re: systemd: Yet Another Init Replacement

#441 2011-04-23 13:14:09

Re: systemd: Yet Another Init Replacement

#442 2011-04-23 13:41:44

Re: systemd: Yet Another Init Replacement

#443 2011-04-23 14:14:19

Re: systemd: Yet Another Init Replacement

#444 2011-04-23 14:28:46

Re: systemd: Yet Another Init Replacement

#445 2011-04-23 14:32:11

Re: systemd: Yet Another Init Replacement

#446 2011-04-23 15:32:28

Re: systemd: Yet Another Init Replacement

#447 2011-04-24 09:07:36

Re: systemd: Yet Another Init Replacement

#448 2011-04-24 09:48:26

Re: systemd: Yet Another Init Replacement

#449 2011-04-24 10:27:33

Re: systemd: Yet Another Init Replacement

#450 2011-04-24 13:28:18

Re: systemd: Yet Another Init Replacement

Board footer