systemd: Yet Another Init Replacement

tomegun · 2011-07-30 00:44:10

@bart_vv:

That should definitely work. I'm wondering if there might be something wrong with the service file though. Could you try this instead?

[Unit]
Description=/etc/rc.local Compatibility

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/etc/rc.local
ExecStop=/etc/rc.local.shutdown
TimeoutSec=0
StandardInput=tty
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

zenlord · 2011-07-30 09:33:11

Thank you all for the perfect documentation - it helped me convert to systemd in about 20 minutes (after I had been holding this off for a while now). I read the wiki, I have read some of Lennart's earlier blogposts about systemd and am wondering where to go from here. I saw in this thread that you can analyze the blame, and that will lead to faster boottimes I guess.

I have already disabled NetworkManager.service and enabled the -wait-online-version, as nm was taking by far the longest to boot (understandable, but still)

Right now, I have 2 failed services:

# systemctl status gamin.service
gamin.service - Legacy unit for gamin.service
   Loaded: loaded (/run/systemd/generator/arch-daemons.target.wants/gamin.service)
   Active: failed since Sat, 30 Jul 2011 11:25:45 +0200; 16s ago
   Process: 1869 ExecStart=/etc/rc.d/gamin start (code=exited, status=203/EXEC)
   CGroup: name=systemd:/system/gamin.service

... and another one, but the name is too long to be displayed correctly in 'systemctl' - the name starts with systemd-... and the description is 'Load kernel modules' and it has the word 'failed' next to it in both columns.

Appreciate any help, and thx again for these packages.

litemotiv · 2011-07-30 09:42:59

I thought gamin shouldn't be needed to run as a service/daemon as it can be started by programs in place? Which package actually provides that daemon, i don't believe it's gamin itself?

zenlord · 2011-07-30 10:11:16

There seems to not be a gamin.service file in /etc/... or /lib/... .

The gamin-package does not provide this service-file. I'm sorry I cannot be of much help, since I'm still figuring the possibilities of systemctl out. I can provide you with this, to show you what systemd has loaded on my laptop:

# systemd-analyze blame
  9880ms pommed.service
  9867ms NetworkManager.service
  7981ms laptop-mode-tools.service
  6373ms php-fpm.service
  4610ms modem-manager.service
  4567ms nginx.service
  4360ms bluetooth.service
  3276ms cpufreq.service
  2176ms laptop-mode.service
  2033ms crond.service
  1609ms systemd-vconsole-setup.service
   843ms systemd-tmpfiles-setup.service
   833ms rfkill.service
   759ms udev-trigger.service
   686ms systemd-remount-api-vfs.service
   660ms udev.service
   620ms dbus.service
   613ms media.mount
   584ms var-run.mount
   491ms var-lock.mount
   486ms console-kit-log-system-start.service
   476ms syslog-ng.service
   469ms systemd-sysctl.service
   456ms systemd-user-sessions.service
   453ms networkmanager.service
   222ms accounts-daemon.service
   165ms cups.service
   118ms console-kit-daemon.service
    49ms rtkit-daemon.service
    36ms remount-rootfs.service

THX!

Zom · 2011-07-30 10:51:12

I don't think you need a service file for gamin, it should start automatically once it's needed.

tomegun · 2011-07-30 11:06:08

zenlord wrote:

Thank you all for the perfect documentation - it helped me convert to systemd in about 20 minutes (after I had been holding this off for a while now). I read the wiki, I have read some of Lennart's earlier blogposts about systemd and am wondering where to go from here. I saw in this thread that you can analyze the blame, and that will lead to faster boottimes I guess.
I have already disabled NetworkManager.service and enabled the -wait-online-version, as nm was taking by far the longest to boot (understandable, but still)

Your boot should not wait for NetworkManager to start, so it is ok that it takes a long time. What -wait-online does, is to make sure network.target is not started until your network is up. This could slow down your boot if something is "After=network.target" (some things, such as nfs needs it though).

zenlord wrote:

Right now, I have 2 failed services:
# systemctl status gamin.service
gamin.service - Legacy unit for gamin.service
   Loaded: loaded (/run/systemd/generator/arch-daemons.target.wants/gamin.service)
   Active: failed since Sat, 30 Jul 2011 11:25:45 +0200; 16s ago
   Process: 1869 ExecStart=/etc/rc.d/gamin start (code=exited, status=203/EXEC)
   CGroup: name=systemd:/system/gamin.service
... and another one, but the name is too long to be displayed correctly in 'systemctl' - the name starts with systemd-... and the description is 'Load kernel modules' and it has the word 'failed' next to it in both columns.

gamin is started because you have it in your daemons array. I would try starting /etc/rc.d/gamin maunally, to see if that works, maybe it needs to be ordered after something (I don't use gamin so I don't even know what it does).

To see the full name of your service file do "systemctl --full". Probably the failure you are seeing is that some module can not be loaded. Have a look in dmsg for failed module load (your could do "systemctl restart systemd-modules-load.service" to make sure the errors are at the bottom of your dmesg). Then have a look in /etc/module-load.d/*.conf to see what modules are being loaded.

bart_vv · 2011-07-30 11:16:50

@tomegun:

Adding Type=oneshot did it, for what I am very grateful to you, thanks. Service file was arch's default, so I wonder if there will be more people like me asking themselves why sleep doesn't work. Oh, and there are two RemainAfterExit in [service] in your example, don't know if it's intended.

Thanks again.

litemotiv · 2011-07-30 11:18:27

tomegun wrote:

gamin is started because you have it in your daemons array.

Ah that must be it, he probably changed fam (which does need to run as a daemon) for gamin at one point in modules().

Stebalien · 2011-07-31 22:31:46

Is there any way to stop the bluetooth daemon when the bluetooth dongle is removed? The bluetooth target stops but I can't get the bluetooth service to stop.
- Adding 'BindTo=bluetooth.target' to the bluetooth.service file keeps the target from stopping but does not kill the daemon. When I then plug my bluetooth dongle back in, bluetootd segfauls with:

Jul 31 15:23:06 localhost kernel: usb 6-2: new full speed USB device number 9 using uhci_hcd
Jul 31 15:23:06 localhost kernel: bluetoothd[30659] general protection ip:7f994063fb75 sp:7fff42cf52b0 error:0 in libglib-2.0.so.0.2800.8[7f99405e2000+e9000]

- Adding 'StopWhenUnneeded=true' to the bluetooth service file doesn't do anything (unless I call systemctl daemon-reload).

-- PS: While going through my logs, I noticed that ufw.service has an ExecRestart (which doesn't exist).

ron9 · 2011-08-02 09:24:18

litemotiv wrote:

ron9, your udev-trigger.service call seems quite slow, i wonder why that is.
tomegun wrote:
The call to trigger should be instantaneous, so (unless there is a bug in udev), this is just a side-effect of having a slow HDD.

dmesg | grep failed:
udevd[484]: failed to execute '/lib/udev/load-modules.sh' '/lib/udev/load-modules.sh pcmcia': No such file or directory
dmesg | grep error:
udevd[794]: error: runtime directory '/run/udev' not writable, for now falling back to '/dev/.udev'
udevd[796]: error binding udev control socket

I have these error messages. Could it have something to do with udev-trigger.service spend so much time?
Or maybe this has nothing to do with systemd.

tomegun · 2011-08-02 10:56:56

ron9 wrote:

udevd[484]: failed to execute '/lib/udev/load-modules.sh' '/lib/udev/load-modules.sh pcmcia': No such file or directory
dmesg | grep error:
udevd[794]: error: runtime directory '/run/udev' not writable, for now falling back to '/dev/.udev'
udevd[796]: error binding udev control socket
I have these error messages. Could it have something to do with udev-trigger.service spend so much time?
Or maybe this has nothing to do with systemd.

Probably not the reason for the slowdown. However, those messages should not be there. Are you using the most recent mkinitcpio? The first error is a known bug in out pcmcia package, hopefully this should be fixed soon...

ron9 · 2011-08-02 11:27:27

tomegun wrote:

Probably not the reason for the slowdown. However, those messages should not be there. Are you using the most recent mkinitcpio? The first error is a known bug in out pcmcia package, hopefully this should be fixed soon...

The second errormessage is gone after reboot. So then just have to wait for a fix for the first one. (I'm using mkinitcpio 0.7.2-1.)

Last edited by ron9 (2011-08-02 11:44:50)

tomegun · 2011-08-02 11:43:57

The first message is this bug: <https://bugs.archlinux.org/task/25026>. I'll poke the report again.

ron9 · 2011-08-02 11:48:01

I'm sorry I corrected my post while you answered!
Thanks for the quick reply

sylock · 2011-08-03 22:24:27

Hello Guys,

I wanted to try systemd. After some tweaks it works but I have a problem with sound that I can't fix. If I reboot arch and start from the standard init then I have the sound back.

In fact,
- kernel modules seems to be loaded correctly (same names and number between init and systemd)
- content of /dev/snd/ seems to be the same

But
- aplay -l says there are no audio cards with systemd
- fuser -v /dev/snd/* gives me nothing with systemd and says that pulse audio is using the socket on an init session

Is someone have an idea?

tomegun · 2011-08-03 23:07:44

sylock wrote:

I wanted to try systemd. After some tweaks it works but I have a problem with sound that I can't fix. If I reboot arch and start from the standard init then I have the sound back.
In fact,
- kernel modules seems to be loaded correctly (same names and number between init and systemd)
- content of /dev/snd/ seems to be the same
But
- aplay -l says there are no audio cards with systemd
- fuser -v /dev/snd/* gives me nothing with systemd and says that pulse audio is using the socket on an init session

I just realised after you left #systemd that the problem might be that you are not using the systemd pam module. I did not know that this is needed, but it would make sense.

Try adding

session required pam_systemd.so

at the end of each of /etc/pam.d/{login,sshd,kde,kde-np} and any files related to whatever your DE is (gnome/xfce/...).

Maybe falconindy knows more about this?

dimitar · 2011-08-03 23:33:36

sylock wrote:

After some tweaks it works but I have a problem with sound that I can't fix. If I reboot arch and start from the standard init then I have the sound back.

I have a similar problem and I posted it here. I think the problem is that pulseaudio does not communicate correctly with the new version (33-1) of udev.

sylock wrote:

- aplay -l says there are no audio cards with systemd

Try starting aplay without pulseaudio running, i.e. in console mode or try killing pulseaudio. Then, it'll see your card.

I'd appreciate any help, too

tomegun · 2011-08-03 23:35:48

dimitar wrote:

I'd appreciate any help, too

Do you have the pam module enabled as I mentioned in my previous post? Could you (both of you) post the output of:

# dmesg | grep systemd

?

falconindy · 2011-08-03 23:44:46

Can't reproduce this. I removed myself from the audio group and disabled pam_systemd from login. Sound via pulse (and alsa) still works just fine.

dimitar · 2011-08-04 05:41:39

tomegun wrote:

dimitar wrote:
I'd appreciate any help, too
Do you have the pam module enabled as I mentioned in my previous post? Could you (both of you) post the output of:
# dmesg | grep systemd
?

Adding pam_systemd.so to /etc/pam.d/{kde,kde-np} solved my issue (at least in KDE4; I'll check again with other DEs later, too)!

Anyway here is the dmesg output, too:

$ dmesg | grep systemd
[    0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz26 root=/dev/disk/by-uuid/bf592b9c-bb2c-4725-b700-de23e412a162 ro init=/bin/systemd resume=/dev/disk/by-uuid/afa06969-eadb-4516-b761-8a641b3be442 pcie_aspm=force quiet splash
[    0.000000] Kernel command line: BOOT_IMAGE=/boot/vmlinuz26 root=/dev/disk/by-uuid/bf592b9c-bb2c-4725-b700-de23e412a162 ro init=/bin/systemd resume=/dev/disk/by-uuid/afa06969-eadb-4516-b761-8a641b3be442 pcie_aspm=force quiet splash
[    5.758953] systemd[1]: systemd 33 running in system mode. (+PAM -LIBWRAP -AUDIT -SELINUX +SYSVINIT +LIBCRYPTSETUP; arch)
[    6.123935] systemd[1]: Set hostname to <darkrider>.
[    9.491974] systemd-fsck[327]: root: clean, 454468/1379040 files, 4968547/5506270 blocks
[   11.380037] systemd-tmpfiles[593]: Two or more conflicting lines for /tmp configured, ignoring.
[   11.385542] systemd-tmpfiles[593]: Two or more conflicting lines for /tmp/.X11-unix configured, ignoring.
[   11.385549] systemd-tmpfiles[593]: Two or more conflicting lines for /tmp/.ICE-unix configured, ignoring.
[   11.385555] systemd-tmpfiles[593]: Two or more conflicting lines for /tmp/.XIM-unix configured, ignoring.
[   11.385561] systemd-tmpfiles[593]: Two or more conflicting lines for /tmp/.font-unix configured, ignoring.
[   11.385569] systemd-tmpfiles[593]: Two or more conflicting lines for /tmp/.Test-unix configured, ignoring.

The +PAM option is present both with and without pam_systemd.so. The user I use is not member of the group audio:

$ groups                                                                                                                                     
wheel uucp kvm video users sudo vboxusers

I don't know why pam_systemd.so fixed the issue, but many, many thanks, tomegun (at one point I thought I was doomed to downgrade )!!!

sylock · 2011-08-04 07:26:51

Like dimitar : even if I don't understand why adding the required statement into pam modules resolved my sound problem!

Many many thanks tomegun

If someone have an explanation I would thank him

tomegun · 2011-08-04 09:30:41

sylock wrote:

If someone have an explanation I would thank him

I'm still not 100% on top of things when it comes to the new logind stuff. However, this is my take on it:

systemd is intending to take over the role of consolekit (I think most, if not all, of the functionality has already been merged). In particular it intends to make multi seat "Just Work" (TM), which for some reason it did not with consolekit (don't ask me about the technicalities).

pam_systemd.so interacts with systemd-logind to set up a new seat/session when you log in. You can see this in your dmesg if you grep for "logind":

[ 13.467574] systemd-logind[451]: New seat seat0.
[ 14.015903] systemd-logind[451]: New user teg logged in.
[ 14.015910] systemd-logind[451]: New session c1 of user teg.
[ 14.040190] systemd-logind[451]: Linked /tmp/.X11-unix/X0 to /run/user/teg/X11/display.

One of the things this does is to deal with acl. That is, it makes sure that the current user has the right permissions to all the relevant devices (such as sound). This is needed by e.g. pulseaudio if you use it properly (i.e., you are not in the "audio" group).

Back in the day (last week or so), this was done by consolekit. To avoid systemd-logind and consolekit stepping on eachother's toes udev detects when systemd is running and avoids applying the acl stuff that consolekit needs. In Arch we still enable the acl stuff at compile-time, so in the case when you boot with sysvinit everything works as before.

Hope that helps, and if anyone notice any misstakes or omissions in my explanation, please point them out

franz1789 · 2011-08-12 13:16:57

$ dmesg | grep ntfs
[ 10.178161] systemd-fsck[677]: fsck: fsck.ntfs-3g: not found
[ 10.178179] systemd-fsck[404]: /sbin/fsck: Error 2 while executing fsck.ntfs-3g for /dev/sda1

I've got these errors at boot, how can I solve it? I didn't find anything searching on the forum..

Gullible Jones · 2011-08-12 15:49:15

tomegun wrote:

sylock wrote:
If someone have an explanation I would thank him
I'm still not 100% on top of things when it comes to the new logind stuff. However, this is my take on it:
systemd is intending to take over the role of consolekit (I think most, if not all, of the functionality has already been merged). In particular it intends to make multi seat "Just Work" (TM), which for some reason it did not with consolekit (don't ask me about the technicalities).

Ooh, ooh! Does this mean that at some point it'll be a choice of using systemd or having no automounting? Because that would really be wonderful, and I mean that in the most sarcastic way possible.

tomegun · 2011-08-12 17:36:56

Gullible Jones wrote:

tomegun wrote:
systemd is intending to take over the role of consolekit (I think most, if not all, of the functionality has already been merged). In particular it intends to make multi seat "Just Work" (TM), which for some reason it did not with consolekit (don't ask me about the technicalities).
Does this mean that at some point it'll be a choice of using systemd or having no automounting?

In principle there is no obstacle to using systemd-logind in exactly the same way as consolekit was used (via pam and with sysvinit as the init system). However, I don't know if the code is in place for this to actually work. I guess (unless there is some technical obstacle that I'm unaware of), patches to make this work would be welcome. [Take this with a pinch of salt, as I said I'm not 100% sure how everything fits together in this corner of systemd.]

Nothing is preventing you from continuing to use (and maintain) consolekit. The way udev handles this means that both consolekit and systemd will continue to work.

Arch Linux

#876 2011-07-30 00:44:10

Re: systemd: Yet Another Init Replacement

#877 2011-07-30 09:33:11

Re: systemd: Yet Another Init Replacement

#878 2011-07-30 09:42:59

Re: systemd: Yet Another Init Replacement

#879 2011-07-30 10:11:16

Re: systemd: Yet Another Init Replacement

#880 2011-07-30 10:51:12

Re: systemd: Yet Another Init Replacement

#881 2011-07-30 11:06:08

Re: systemd: Yet Another Init Replacement

#882 2011-07-30 11:16:50

Re: systemd: Yet Another Init Replacement

#883 2011-07-30 11:18:27

Re: systemd: Yet Another Init Replacement

#884 2011-07-31 22:31:46

Re: systemd: Yet Another Init Replacement

#885 2011-08-02 09:24:18

Re: systemd: Yet Another Init Replacement

#886 2011-08-02 10:56:56

Re: systemd: Yet Another Init Replacement

#887 2011-08-02 11:27:27

Re: systemd: Yet Another Init Replacement

#888 2011-08-02 11:43:57

Re: systemd: Yet Another Init Replacement

#889 2011-08-02 11:48:01

Re: systemd: Yet Another Init Replacement

#890 2011-08-03 22:24:27

Re: systemd: Yet Another Init Replacement

#891 2011-08-03 23:07:44

Re: systemd: Yet Another Init Replacement

#892 2011-08-03 23:33:36

Re: systemd: Yet Another Init Replacement

#893 2011-08-03 23:35:48

Re: systemd: Yet Another Init Replacement

#894 2011-08-03 23:44:46

Re: systemd: Yet Another Init Replacement

#895 2011-08-04 05:41:39

Re: systemd: Yet Another Init Replacement

#896 2011-08-04 07:26:51

Re: systemd: Yet Another Init Replacement

#897 2011-08-04 09:30:41

Re: systemd: Yet Another Init Replacement

#898 2011-08-12 13:16:57

Re: systemd: Yet Another Init Replacement

#899 2011-08-12 15:49:15

Re: systemd: Yet Another Init Replacement

#900 2011-08-12 17:36:56

Re: systemd: Yet Another Init Replacement

Board footer