Archlinux is moving to systemd

cfr · 2012-08-31 21:47:26

I'm still not getting how to work out the relationship between different services.

systemctl list-unit-files

lists things nicely but I can't see how to infer why certain things are started (what starts what, say).

journalctl

gives me a lot but it just tells me (I think) that dbus starts colord-sane.service, for example. (Hard to be sure as the lines are too wide for my screen and it doesn't seem to believe in wrapping them.) But I take it that dbus is not necessarily the instigator i.e. it isn't that dbus "requires" or "wants" the service.

Somebody mentioned that cups starts colord.service and colord-sane.service. How can I know that without somebody telling me here? That is, how would I find that out for myself? I've read cups.service, cups.socket and cups.path and none of them mention colord.service or colord-sane.service. In fact, I can't tell from reading those files that cups requires or wants anything at all except for a path (/var/spool/cups/d*) and a socket (/var/run/cups/cups.sock). They tell me it is wanted by various targets (printer, multi-user etc.) but that's presumably a different issue.

blackout23 · 2012-08-31 22:24:01

anonymous_user wrote:

Have you tried using tab completion? systemctl enable <tab>
Or maybe something like "systemctl list-units --all | grep .service".
edit: too late

Autocompletion doesn't work after you completed the "systemctl" command. It won't even complete "enable" when you have "systemctl en<tab>". I don't know
what part of the system is repsonsible for autocompletion but I heard that in Fedora it actually works for systemctl parameters. I wish I could get better autocompletion
for my linux desktop. It seems that it can only complete one command and get the file path right if you use it as a parameter for example in "dd". But even when you
use "sudo" in front of a command you can't complete the second command. Do I need something better than bash?

EDIT: It completes sudo systemctl it just kicks in very late because there are way to many commands with system. Autocompleting Parameters in every program would
be super awesome. But there is no way how bash could know all available parameters I guess.

Last edited by blackout23 (2012-08-31 22:37:28)

bohoomil · 2012-08-31 22:37:33

blackout23 wrote:

Autocompletion doesn't work after you completed the "systemctl" command. It won't even complete "enable" when you have "systemctl en<tab>".

It does work very well for me. core/systemd provides the necessary completion files for bash.

D4ve · 2012-08-31 23:16:21

@cfr: I've found something cool to see the dependencies:

# First, install the programm dot
$ sudo pacman -S graphviz
# Then generate .svg from your boot
$ systemctl dot | dot -Tsvg > systemd.svg

You should generate a png or jpg file from the svg, otherwise your computer will hang on opening the svg-file

EDIT: Autocompletion of "systemctl ..." doesn't work for me

Last edited by D4ve (2012-08-31 23:17:59)

AaronBP · 2012-08-31 23:27:39

Doesn't work for me either for whatever reason. I put this in my bashrc:

sysenable() {
	for i in "$@"; do
		sudo systemctl enable "$i".service
	done
}

sysdisable() {
	for i in "$@"; do
		sudo systemctl disable "$i".service
	done
}

karabaja4 · 2012-09-01 00:09:27

I noticed something odd when booting with systemd. I solved it, but I would like some thoughts on this.

I have a LVM array with few disks including some external USB drives. Before the actual systemd boot, the array is scanned and if all drives are found, it will report something along the lines of this:

1 logical volume(s) in volume group "diskovi0" now active

however, what sometimes happenes is that USB drives are late in initializing and this causes the detection to fail.

Refusing activation of partial LV media. Use --partial to override.
0 logical volume(s) in volume group "diskovi0" now active

This was not a problem with initscripts because somewhere along the boot process LVM array would be successfully detected and mounted.

However, when LVM drive detection fails and when using systemd, the boot process just freezes after

[OK] Mounted /home.

and it just stays there until I force restart.

I solved this by adding lvm service to systemd:

systemctl enable lvm.service

and now it boots fine. Anyway, why does this happen? If LVM array is successfully detected there is no need for systemd LVM service? Why? Also, why doesn't systemd report what the problem is, instead of just stalling and forcing the user to guess what the problem is?

ataraxia · 2012-09-01 00:27:10

cfr wrote:

I'm still not getting how to work out the relationship between different services.
systemctl list-unit-files
lists things nicely but I can't see how to infer why certain things are started (what starts what, say).
journalctl
gives me a lot but it just tells me (I think) that dbus starts colord-sane.service, for example. (Hard to be sure as the lines are too wide for my screen and it doesn't seem to believe in wrapping them.) But I take it that dbus is not necessarily the instigator i.e. it isn't that dbus "requires" or "wants" the service.
Somebody mentioned that cups starts colord.service and colord-sane.service. How can I know that without somebody telling me here? That is, how would I find that out for myself? I've read cups.service, cups.socket and cups.path and none of them mention colord.service or colord-sane.service. In fact, I can't tell from reading those files that cups requires or wants anything at all except for a path (/var/spool/cups/d*) and a socket (/var/run/cups/cups.sock). They tell me it is wanted by various targets (printer, multi-user etc.) but that's presumably a different issue.

I'm the poster who reported that cups starts colord, and there are two answers to this:

- I had to learn it by "science", i.e., trying different things and seeing when colord was started, and when it was not. There's not really anything to read (other than cups source code, I guess) which would tell you that it would work this way. And that's because...

- This actually has nothing to do with systemd. cups would send DBus messages to colord under sysvinit just the same, and dbus-daemon would start it up just the same. There's a slight difference in how colord would be started, depending on if you're using sysvinit or systemd. Under sysvinit dbus just runs colord directly, under systemd it uses "systemctl start". You can see what it will do in each case by looking at the relevant file under /usr/share/dbus-1/system-services/ (in this case "org.freedesktop.ColorManager.service"). DBus calls "systemctl start" on the unit named under SystemdService if it's running under systemd (which it knows because it's been passed the "--systemd-activation" flag), and runs the "Exec" command directly otherwise.

cfr · 2012-09-01 00:33:02

Is anybody having trouble with bluetooth? Mine is showing as hard blocked but it shouldn't be. (This was a problem earlier but it was solved by a BIOS upgrade several months ago.)

I can't think why this issue should re-emerge with systemd.

@D4ve,
I tried the dot trick. The .svg works fine on my machine. At least, it opens OK. Could you make anything of yours? Mine is useless - a horribly jumbled mess of lines which it is impossible to follow with oval shapes representing units arranged either randomly or according to some arcane order to whose secret I am not privy.

blackout23 · 2012-09-01 01:02:03

I'm now a zsh user and I am IMPRESSED! It completes everything and shows my *.service files. Also love the configuration script run when you start it for the first time.

cfr · 2012-09-01 02:24:53

ataraxia wrote:

I'm the poster who reported that cups starts colord, and there are two answers to this:
- I had to learn it by "science", i.e., trying different things and seeing when colord was started, and when it was not. There's not really anything to read (other than cups source code, I guess) which would tell you that it would work this way. And that's because...
- This actually has nothing to do with systemd. cups would send DBus messages to colord under sysvinit just the same, and dbus-daemon would start it up just the same. There's a slight difference in how colord would be started, depending on if you're using sysvinit or systemd. Under sysvinit dbus just runs colord directly, under systemd it uses "systemctl start". You can see what it will do in each case by looking at the relevant file under /usr/share/dbus-1/system-services/ (in this case "org.freedesktop.ColorManager.service"). DBus calls "systemctl start" on the unit named under SystemdService if it's running under systemd (which it knows because it's been passed the "--systemd-activation" flag), and runs the "Exec" command directly otherwise.

Thanks for that very detailed explanation. I'm somewhat disappointed (in systemd - not the explanation) because I thought systemd was supposed to make this kind of information transparent.

I'm also confused. I can't find any mention of colord (or colord-sane) in /var/log/boot or /var/log/dmesg.log. Is that because under sysvinit, dbus starts it automatically on request from cups? So the following code:

[D-BUS Service]
Name=org.freedesktop.ColorManager
Exec=/usr/lib/colord/colord
User=root
SystemdService=colord.service

means that dbus will execute the Exec line directly under sysvinit or start the SystemdService under systemd? And maybe that's why the Exec line in /usr/share/dbus-1/system-services/org.freedesktop.login1.service is /bin/false? (Because the thing shouldn't start at all under sysvinit?)

But I'm still a bit surprised colord doesn't show up in the boot log for sysvinit - even if it is started via dbus...

ataraxia · 2012-09-01 02:35:18

cfr wrote:

ataraxia wrote:
I'm the poster who reported that cups starts colord, and there are two answers to this:
- I had to learn it by "science", i.e., trying different things and seeing when colord was started, and when it was not. There's not really anything to read (other than cups source code, I guess) which would tell you that it would work this way. And that's because...
- This actually has nothing to do with systemd. cups would send DBus messages to colord under sysvinit just the same, and dbus-daemon would start it up just the same. There's a slight difference in how colord would be started, depending on if you're using sysvinit or systemd. Under sysvinit dbus just runs colord directly, under systemd it uses "systemctl start". You can see what it will do in each case by looking at the relevant file under /usr/share/dbus-1/system-services/ (in this case "org.freedesktop.ColorManager.service"). DBus calls "systemctl start" on the unit named under SystemdService if it's running under systemd (which it knows because it's been passed the "--systemd-activation" flag), and runs the "Exec" command directly otherwise.
Thanks for that very detailed explanation. I'm somewhat disappointed (in systemd - not the explanation) because I thought systemd was supposed to make this kind of information transparent.

Well, it's not very fair to blame systemd for this problem, as it's quite outside of its purview. The lack of transparency of DBus bus-activation predates systemd by quite a bit, and is basically outside systemd's reach to improve.

cfr wrote:

I'm also confused. I can't find any mention of colord (or colord-sane) in /var/log/boot or /var/log/dmesg.log. Is that because under sysvinit, dbus starts it automatically on request from cups? So the following code:
[D-BUS Service]
Name=org.freedesktop.ColorManager
Exec=/usr/lib/colord/colord
User=root
SystemdService=colord.service
means that dbus will execute the Exec line directly under sysvinit or start the SystemdService under systemd? And maybe that's why the Exec line in /usr/share/dbus-1/system-services/org.freedesktop.login1.service is /bin/false? (Because the thing shouldn't start at all under sysvinit?)
But I'm still a bit surprised colord doesn't show up in the boot log for sysvinit - even if it is started via dbus...

Yes, you understand it correctly. And you won't see colord in the boot log under sysvinit because it's the rc.d script which would have written something there, not colord itself (and as you understood, DBus skips the rc.d script and runs /usr/lib/colord/colord, the actual daemon, directly).

That's exactly the right understanding for why login1 has Exec=/bin/false, also.

D4ve · 2012-09-01 12:31:27

cfr wrote:

Is anybody having trouble with bluetooth? Mine is showing as hard blocked but it shouldn't be

Well, i have another problem with bluetooth: I can't block it on startup. If i login and block it with rfkill it works, but i can't control that with systemd.

cfr wrote:

I tried the dot trick. The .svg works fine on my machine. At least, it opens OK. Could you make anything of yours? Mine is useless - a horribly jumbled mess of lines which it is impossible to follow with oval shapes representing units arranged either randomly or according to some arcane order to whose secret I am not privy.

I did not say that it is useful

But you're right, it is very hard to see the dependencies. Have you tried systemctl dot? I think that's at least a start, even if it is not yet really useful.

Would be nice if someone could write a small script that translates the output to something easier to interpret.

Runiq · 2012-09-01 13:13:30

D4ve wrote:

cfr wrote:
I tried the dot trick. The .svg works fine on my machine. At least, it opens OK. Could you make anything of yours? Mine is useless - a horribly jumbled mess of lines which it is impossible to follow with oval shapes representing units arranged either randomly or according to some arcane order to whose secret I am not privy.
I did not say that it is useful
But you're right, it is very hard to see the dependencies. Have you tried systemctl dot? I think that's at least a start, even if it is not yet really useful.
Would be nice if someone could write a small script that translates the output to something easier to interpret.

the -T parameter to dot specifies the type. If you use

$ systemctl dot | dot -Tpng > systemd.png

you get a png instead.

cfr · 2012-09-01 14:23:08

@D4ve,
If you were previously using config under /etc/conf.d to specify what rfkill should block on startup, it won't work with systemd because the rfkill.service doesn't read your config. You need to either create a new service or copy rfkill.service to /etc/systemd/system and edit it before enabling either rfkill or your custom service. If your parameters are not very simple, you may need more than one command line to be passed.

@Runiq,
I didn't know that but it doesn't help much. The main problem is not the format of the graphic file but the contents which is unintelligible!

progandy · 2012-09-01 14:33:11

cfr wrote:

@Runiq,
I didn't know that but it doesn't help much. The main problem is not the format of the graphic file but the contents which is unintelligible!

You could try this python script, maybe that helps if you want to search for dependencies of a specific unit
http://pastebin.com/NvyqRBh5
Edit: With a little effort you can reverse the data in order to show "required by" instead of "requires"

Last edited by progandy (2012-09-01 14:35:28)

D4ve · 2012-09-01 15:28:00

cfr wrote:

If you were previously using config under /etc/conf.d to specify what rfkill should block on startup, it won't work with systemd because the rfkill.service doesn't read your config. You need to either create a new service or copy rfkill.service to /etc/systemd/system and edit it before enabling either rfkill or your custom service. If your parameters are not very simple, you may need more than one command line to be passed.

I used an entry in my /etc/rc.local (yes, i know rc.local can be used with systemd too), but i don't want to use rc.local because i think support for it will be dropped. I'll try to write a custom rfkill.service-file, that's a good idea.

EDIT: I've found something interesting: If i login to my htpc over ssh and run "systemctl poweroff", my htpc shuts down but doesn't close the ssh-connection. Also i don't get a shutdown-message or something like that. Can anyone confirm this?

Last edited by D4ve (2012-09-01 17:23:30)

cfr · 2012-09-01 23:37:33

Don't know if this helps at all:

$ cat /etc/systemd/system/rfkill-unblock.service 
[Unit]
Description=RFKill-Unblock All Devices

[Service]
Type=oneshot
ExecStart=/usr/sbin/rfkill unblock all
ExecStop=
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

I realise you are trying to do the opposite but I assume that's a simple switch. I think you can only pass one parameter at a time to rfkill so you may need a separate command line for each one. I think you can have multiple ExecStart lines if the service is of type "oneshot" but don't hold me to that as I haven't tried it.

$ systemctl status rfkill-unblock.service 
rfkill-unblock.service - RFKill-Unblock All Devices
          Loaded: loaded (/etc/systemd/system/rfkill-unblock.service; enabled)
          Active: active (exited) since Sat, 01 Sep 2012 23:53:56 +0100; 39min ago
         Process: 393 ExecStart=/usr/sbin/rfkill unblock all (code=exited, status=0/SUCCESS)
          CGroup: name=systemd:/system/rfkill-unblock.service

I just realised that systemd is completely ignoring my locale. The date, at least, should really appear in my language, even if nothing else does, shouldn't it? I get dates in my language at the command line usually:

$ date
Sul  2 Med 00:36:37 BST 2012

Or does systemd use English regardless?

cfr · 2012-09-01 23:41:36

progandy wrote:

You could try this python script, maybe that helps if you want to search for dependencies of a specific unit
http://pastebin.com/NvyqRBh5
Edit: With a little effort you can reverse the data in order to show "required by" instead of "requires"

Thanks! I will definitely take a look at this...

D4ve · 2012-09-01 23:46:35

cfr wrote:

Don't know if this helps at all

It helped, thanks

cfr wrote:

I just realised that systemd is completely ignoring my locale. The date, at least, should really appear in my language, even if nothing else does, shouldn't it? I get dates in my language at the command line usually:
$ date
Sul  2 Med 00:36:37 BST 2012
Or does systemd use English regardless?

Does date really use the locale provided from systemd? I have the same behavior here, but i'm not 100% sure if i set my locale correct.

cfr · 2012-09-02 01:08:39

D4ve wrote:

Does date really use the locale provided from systemd? I have the same behavior here, but i'm not 100% sure if i set my locale correct.

As you can see, on my machine, date uses the locale from /etc/locale.conf. (Well, you can't see it matches but you can presumably see it isn't English.) But systemd apparently ignores locale.conf.

EDIT: You don't really have the same behaviour, do you? What did you set your locale to? The output of date given above is correct for my locale. The output from systemd, however, uses English dates.

Last edited by cfr (2012-09-02 01:13:43)

D4ve · 2012-09-02 01:38:57

Ah, sorry. I misunderstood your previous text. My locale is set to en_US.UTF-8, so there's no difference between the output of date and systemd.

brain0 · 2012-09-02 15:02:33

karabaja4 wrote:

I have a LVM array with few disks including some external USB drives. Before the actual systemd boot, the array is scanned and if all drives are found, it will report something along the lines of this:
1 logical volume(s) in volume group "diskovi0" now active
however, what sometimes happenes is that USB drives are late in initializing and this causes the detection to fail.
Refusing activation of partial LV media. Use --partial to override.
0 logical volume(s) in volume group "diskovi0" now active

First of all, LVM is stupid and has no proper hotplug method. Second, if you activate the LVM in the initramfs (which you don't want to unless you want to boot from it), then use the lvmwait= parameter on the kernel commandline to prevent this problem. Doing this in initramfs may slow down your boot process.

karabaja4 wrote:

This was not a problem with initscripts because somewhere along the boot process LVM array would be successfully detected and mounted.

Also because initscripts were too slow to activate before the USB settled.

karabaja4 wrote:

However, when LVM drive detection fails and when using systemd, the boot process just freezes after
[OK] Mounted /home.
and it just stays there until I force restart.

Never had it freeze, but it probably shouldn't.

karabaja4 wrote:

I solved this by adding lvm service to systemd:
systemctl enable lvm.service
and now it boots fine. Anyway, why does this happen? If LVM array is successfully detected there is no need for systemd LVM service? Why? Also, why doesn't systemd report what the problem is, instead of just stalling and forcing the user to guess what the problem is?

The lvm.service waits for all devices to settle and then enables LVM. As I said before, it is stupid, but there is no better generic way to do it with LVM. For very confusing reasons, it may still fail with USB drives.

On my machine, I have a RAID device (/dev/md1) that I use for my LVM. To make sure it always works and to speed up my boot, I disabled lvm.service and put this file to /etc/systemd/system/basic.target.wants/lvm_local.service:

[Unit]
Description=LVM activation
Wants=status sys-devices-virtual-block-md1.device
After=status sys-devices-virtual-block-md1.device
Before=basic.target shutdown.target
Conflicts=shutdown.target

[Service]
ExecStart=/sbin/vgchange --available y
Type=oneshot
TimeoutSec=0
RemainAfterExit=yes

[Install]
WantedBy=basic.target

This waits for my md1 device to appear before I activate LVM. This saves me 10 seconds, as settling udev on that machine takes forever. Something similar may also work for your USB drives.

Last edited by brain0 (2012-09-02 15:03:10)

cfr · 2012-09-03 01:47:56

Is there any documentation on configuring laptop stuff for systemd? The wiki pages for pm-utils and acpid don't seem to mention systemd. The page for laptop-mode-tools does but I'm not clear whether anything needs to be adapted beyond enabling the service rather than adding the daemon to rc.conf. Moreover, I can't find anything on how KDE/KDM handles sleep/hibernate etc.

I'm also having a lot of trouble with power generally. With systemd, I can't reboot. reboot powers off the machine instead whether I reboot through KDM or from the command line. (I've adapted the commands in kdmrc for system halt and reboot but I'm not sure where to find equivalents for sleep/suspend/hibernate.)

EDIT: I just found the systemd page says something. I was sure I'd looked here but obviously not. I don't think it is enough but maybe I can generate a more intelligent question...

Last edited by cfr (2012-09-03 01:51:40)

.:B:. · 2012-09-03 01:51:29

Systemd can manage suspend etc. itself. So pm-utils is redundant. I thought there was a bit of info on that in the wiki's systemd entry though.

cfr · 2012-09-03 02:10:22

Thanks, .:B:.. My edit crossed your post. I was positive I'd been through the systemd page but must not have and then I kept looking on all the "power management" pages because that's where I looked when setting this stuff up last year...

Is there an equivalent of on_ac_power? Various scripts use this, including anacron and my own backup script. (I might have edited the anacron one - I don't recall.)

On can I just copy that script to /usr/local and keep using it after uninstalling pm-utils?

I'm currently getting double suspends with the sleep key even though systemd shouldn't be handling it under KDE and I'm not sure why. Usually, acpid handles this, triggering:

echo -n mem >/sys/power/state

Should I not be doing this under systemd? The wiki says that DEs such as gnome etc. should handle these events themselves (rather than systemd). KDE has options to handle power button and lid but not the sleep button.

I've told systemd to handle the power button only if no-session and both the sleep key and lid only if tty-session. So I'm rather confused about the behaviour with the sleep button. systemd shouldn't be handling it; KDE doesn't offer that facility; only acpid seems to be handling it and yet with systemd, sleep happens twice although the screen is only locked the second time. Is there any way that having systemd installed might affect whether KDE handles the sleep button?

I also suspect, though I'm not sure, that pm-utils handled some quirks which systemd doesn't when the system sleeps. The pm-utils/acpid/laptop-mode tools stuff "just worked" but I suspect I need to do some more troubleshooting for systemd to get things working smoothly. Crashing has hard blocked my bluetooth again and I'm getting rather suspicious of the bluetooth modules...

Also, I can't understand why systemd won't reboot rather than powering off the machine and I'm not sure if this is related or not.

EDIT: I can see how to replace some of the pm-utils sleep hooks using the template from the wiki but what I'm not sure about is how to determine which are necessary. Should I, for example, use a hook to disable bluetooth on sleep and maybe see if I can replicate any video-quirks which apply to my machine? Presumably I could then override the sleep hooks from pm-utils with empty files under /etc/pm/sleep.d? (I already do this for the powersaving scripts except cpupower - not sure why I missed that one - because laptop-mode tools handles that.)

I can't uninstall pm-utils or pm-quirks because upower needs them and kdelibs depends on upower. Which makes me wonder how kdelibs is sleeping/suspending the system...

Last edited by cfr (2012-09-03 02:51:19)

Arch Linux

#126 2012-08-31 21:47:26

Re: Archlinux is moving to systemd

#127 2012-08-31 22:24:01

Re: Archlinux is moving to systemd

#128 2012-08-31 22:37:33

Re: Archlinux is moving to systemd

#129 2012-08-31 23:16:21

Re: Archlinux is moving to systemd

#130 2012-08-31 23:27:39

Re: Archlinux is moving to systemd

#131 2012-09-01 00:09:27

Re: Archlinux is moving to systemd

#132 2012-09-01 00:27:10

Re: Archlinux is moving to systemd

#133 2012-09-01 00:33:02

Re: Archlinux is moving to systemd

#134 2012-09-01 01:02:03

Re: Archlinux is moving to systemd

#135 2012-09-01 02:24:53

Re: Archlinux is moving to systemd

#136 2012-09-01 02:35:18

Re: Archlinux is moving to systemd

#137 2012-09-01 12:31:27

Re: Archlinux is moving to systemd

#138 2012-09-01 13:13:30

Re: Archlinux is moving to systemd

#139 2012-09-01 14:23:08

Re: Archlinux is moving to systemd

#140 2012-09-01 14:33:11

Re: Archlinux is moving to systemd

#141 2012-09-01 15:28:00

Re: Archlinux is moving to systemd

#142 2012-09-01 23:37:33

Re: Archlinux is moving to systemd

#143 2012-09-01 23:41:36

Re: Archlinux is moving to systemd

#144 2012-09-01 23:46:35

Re: Archlinux is moving to systemd

#145 2012-09-02 01:08:39

Re: Archlinux is moving to systemd

#146 2012-09-02 01:38:57

Re: Archlinux is moving to systemd

#147 2012-09-02 15:02:33

Re: Archlinux is moving to systemd

#148 2012-09-03 01:47:56

Re: Archlinux is moving to systemd

#149 2012-09-03 01:51:29

Re: Archlinux is moving to systemd

#150 2012-09-03 02:10:22

Re: Archlinux is moving to systemd

Board footer