systemd: Yet Another Init Replacement

falconindy · 2011-09-08 12:58:05

If you want KDM started at boot then, enable the unit and make sure your default.target links to graphical.target.

# systemctl enable kdm.service
# ln -s /lib/systemd/system/default.target /etc/systemd/system/default.target

systemd will not look at /etc/inittab. While there is some glue to allow generation of native unit files for daemons in /etc/rc.conf (via initscripts-systemd), I don't really recommend using it for anything more than a stop gap solution. We have tons of native unit files available.

MisterAnderson · 2011-09-09 03:16:19

Are those softlinks gonna be how final systemd does it or will there be a proper command for that kind of thing?

ron9 · 2011-09-09 06:23:55

"Systemctl enable anything.service" is the systemd command.
It does the same as "ln -s"

Symlink between files.

MisterAnderson · 2011-09-09 14:02:52

ah ok. systemd sounds better and better.

ataraxia · 2011-09-10 01:00:25

So, what are the downsides to using systemd here on Arch at the moment? I'm only aware of a few left:

- util-linux is not compiled with --enable-libmount, so if we make /etc/mtab a symlink to /proc/mounts (as systemd wants), it breaks fuse and some mount options
- missing native unit files for many services, such that we end up using legacy rc.d scripts instead

Anything else like this still to watch out for?

Edit: After trying it again, that second one looks like a much bigger problem than I expected. I was under the impression that I could use rc.d scripts directly somehow ("systemctl enable postfix.service" to run /etc/rc.d/postfix) but that doesn't actually work. How are people getting by without the needed units? About half of the things I want to run don't have units written.

Last edited by ataraxia (2011-09-10 03:18:34)

ChoK · 2011-09-10 10:04:00

from the wiki

arch-daemons.target
Parses the DAEMONS array in /etc/rc.conf and starts the services. If a native systemd unit exists (by the same name) for a given daemon, this is used; otherwise, the script in /etc/rc.d/ is used to control the unit.

ataraxia · 2011-09-10 14:35:30

ChoK wrote:

from the wiki
arch-daemons.target
Parses the DAEMONS array in /etc/rc.conf and starts the services. If a native systemd unit exists (by the same name) for a given daemon, this is used; otherwise, the script in /etc/rc.d/ is used to control the unit.

Yes, I've read the wiki, and I understand the contents of initscripts-systemd (which I don't have installed as I don't intend to use it). It's not what I'm looking for. I don't want everything in DAEMONS to be started by systemd in that manner. I want the ability to selectively do so. After all, "systemctl start postfix.service" works, so why shouldn't "systemctl enable postfix.service"?

I'm getting by now with eight hand-written units to fill the gap. Doing that requires paying attention for when something equivalent shows up in systemd-arch-units or the service's own package so I can drop my hacks, so it's not optimal either.

James_Eder · 2011-09-10 15:14:33

Ataraxia, I believe /etc/rc.d scripts need to have LSB headers (not present in Arch scripts) to be "systemctl enable"d.

Can someone confirm? Having the need for only a couple of unit files, I chose to just write them rather than try to get them working with existing /etc/rc.d scripts.

ataraxia · 2011-09-10 22:44:25

James_Eder wrote:

Ataraxia, I believe /etc/rc.d scripts need to have LSB headers (not present in Arch scripts) to be "systemctl enable"d.

That makes sense, given that my previous experience with this working was in Fedora.

Onward with more questions:

- Where should new service units that I write be submitted for inclusion? systemd-arch-units? The package providing the software in question?

- When I want to modify a (normal) service unit, I copy it to /etc/systemd/system/multi-user.target.wants/ instead of just symlinking, and change the contents. Why can't I do the same with socket units by copying them to /etc/systemd/system/sockets.target.wants/? If I do that, systemd continues to use the version under /lib/systemd/system/ instead of my modified file (even after reboot). I have to actually rename the socket unit (and the associated service unit) for the contents to be respected.

- How do I convert rc.d scripts that do more than one thing, but aren't suitable for "Type=oneshot", to service units? I can't have more than one ExecStart entry for other Types. For example, how would I convert http://projects.archlinux.org/svntogit/ … lm_sensors to a service unit? It first runs "/usr/bin/sensors" (in oneshot fashion), and then runs "/usr/sbin/healthd" (which is a forking daemon). Would I split it in two, with one starting "After" the other?

lymphatik · 2011-09-11 06:56:02

Why do you want to create a service file for lm_sensor ? Because there is already a file doing that in the package

zendeavor · 2011-09-11 08:51:25

as an example, i suspect

ron9 · 2011-09-11 09:09:37

ataraxia wrote:

Where should new service units that I write be submitted for inclusion? systemd-arch-units? The package providing the software in question?

Copy modifyed service and socket files to /etc/systemd/system/ and symlink to one of the "wants" directories. eq multi-user.target.wants or sockets.target.wants
Then execute "sudo systemctl daemon-reload" To activate the new settings.

ataraxia wrote:

How do I convert rc.d scripts that do more than one thing, but aren't suitable for "Type=oneshot", to service units? I can't have more than one ExecStart entry for other Types.

http://0pointer.de/public/systemd-man/s … rvice.html

Last edited by ron9 (2011-09-11 09:15:23)

falconindy · 2011-09-11 14:32:31

ataraxia wrote:

- Where should new service units that I write be submitted for inclusion? systemd-arch-units? The package providing the software in question?

I'd very much prefer that units be submitted upstream before they go to systemd-arch-units.

ataraxia · 2011-09-11 14:53:54

lymphatik wrote:

Why do you want to create a service file for lm_sensor ? Because there is already a file doing that in the package

If you actually read lm_sensors.service, it doesn't start healthd. Did you follow my link? It does something entirely different from what you seem to be expecting.

ataraxia · 2011-09-11 15:01:19

ron9 wrote:

ataraxia wrote:
Where should new service units that I write be submitted for inclusion? systemd-arch-units? The package providing the software in question?
Copy modifyed service and socket files to /etc/systemd/system/ and symlink to one of the "wants" directories. eq multi-user.target.wants or sockets.target.wants
Then execute "sudo systemctl daemon-reload" To activate the new settings.

And I'm pointing out that this doesn't actually work for socket units, even though it does work fine for service units.

ron9 wrote:

ataraxia wrote:
How do I convert rc.d scripts that do more than one thing, but aren't suitable for "Type=oneshot", to service units? I can't have more than one ExecStart entry for other Types.
http://0pointer.de/public/systemd-man/s … rvice.html

Where in that manpage is my question actually answered?

(This part not directed at ron9 in particular) People, stop stop assuming I haven't already read the manpages, wiki page, and upstream web docs for systemd. I've been an Arch user for a long time now - I already know how to RTFM. If my questions were easily answered by doing that, I wouldn't be posting them here. If you haven't got insight on the particular points I'm asking about, then don't waste your time and mine repeating common knowledge here.

Zom · 2011-09-11 16:12:49

ataraxia wrote:

Where in that manpage is my question actually answered?
(This part not directed at ron9 in particular) People, stop stop assuming I haven't already read the manpages, wiki page, and upstream web docs for systemd. I've been an Arch user for a long time now - I already know how to RTFM. If my questions were easily answered by doing that, I wouldn't be posting them here. If you haven't got insight on the particular points I'm asking about, then don't waste your time and mine repeating common knowledge here.

If you think they belong in the same .service-file I suppose you have to use the same type for all of it. If you need to exec more than one thing, you can use the following:

ExecStartPre=, ExecStartPost=
Additional commands that are executed before (resp. after) the command in ExecStart=. Multiple command lines may be concatenated in a single directive, by separating them by semicolons (these semicolons must be passed as separate words). In that case, the commands are executed one after the other, serially. Alternatively, these directives may be specified more than once with the same effect. However, the latter syntax is not recommended for compatibility with parsers suitable for XDG .desktop files. Use of these settings is optional. Specifier and environment variable substitution is supported.

If you need it to be a separate type (like forking), you'd have to create separate .service-files for it, then I suppose you'd use "Requires", "Wants", "Before" or "After" to make it all run in the desired order.

ataraxia · 2011-09-11 16:16:03

Zom wrote:

ataraxia wrote:
Where in that manpage is my question actually answered?
(This part not directed at ron9 in particular) People, stop stop assuming I haven't already read the manpages, wiki page, and upstream web docs for systemd. I've been an Arch user for a long time now - I already know how to RTFM. If my questions were easily answered by doing that, I wouldn't be posting them here. If you haven't got insight on the particular points I'm asking about, then don't waste your time and mine repeating common knowledge here.
If you think they belong in the same .service-file I suppose you have to use the same type for all of it. If you need to exec more than one thing, you can use the following:
ExecStartPre=, ExecStartPost=
Additional commands that are executed before (resp. after) the command in ExecStart=. Multiple command lines may be concatenated in a single directive, by separating them by semicolons (these semicolons must be passed as separate words). In that case, the commands are executed one after the other, serially. Alternatively, these directives may be specified more than once with the same effect. However, the latter syntax is not recommended for compatibility with parsers suitable for XDG .desktop files. Use of these settings is optional. Specifier and environment variable substitution is supported.
If you need it to be a separate type (like forking), you'd have to create separate .service-files for it, then I suppose you'd use "Requires", "Wants", "Before" or "After" to make it all run in the desired order.

Ah, thank you. That looks like just what I need. (Serves me right for complaining that I've already read the docs, and then having it be in there anyway.)

ewaller · 2011-09-11 17:39:53

ataraxia wrote:

...People, stop stop assuming I haven't already read the manpages, wiki page, and upstream web docs for systemd. I've been an Arch user for a long time now - I already know how to RTFM. If my questions were easily answered by doing that, I wouldn't be posting them here. If you haven't got insight on the particular points I'm asking about, then don't waste your time and mine repeating common knowledge here.

Unfortunately (and this is not aimed at you) making that assumption is generally a good first order approximation. Those who do their research bear the burden of being the exception as opposed to the norm. You can mitigate it (somewhat) by declaring that you have done the research up front.

lymphatik · 2011-09-11 19:08:03

ataraxia wrote:

lymphatik wrote:
Why do you want to create a service file for lm_sensor ? Because there is already a file doing that in the package
If you actually read lm_sensors.service, it doesn't start healthd. Did you follow my link? It does something entirely different from what you seem to be expecting.

Well have a look here http://www.lm-sensors.org/browser/lm-se … healthd.sh

healthd is just a script that send email. It is just an example while lm_sensors.service actually launch lm_sensors

And for your information you can launch multiple binaries with execstart

ExecStart=/sbin/ip link set eth0 up ; /sbin/ip addr add 192.168.5.3/24 dev eth0 ; /sbin/ip route add default via 192.168.5.254

And if you had read the manpage you would have found it. man systemd.service line 80.

Last edited by lymphatik (2011-09-11 19:15:04)

ron9 · 2011-09-11 22:02:09

ron9 wrote:

http://0pointer.de/public/systemd-man/s … rvice.html
ataraxia wrote:
Where in that manpage is my question actually answered?

Type=
Configures the process start-up type for this service unit. One of simple, forking, oneshot, dbus, notify.

ExecStartPre=, ExecStartPost=
Additional commands that are executed before (resp. after) the command in ExecStart=. Multiple command lines may be concatenated in a single directive, by separating them by semicolons (these semicolons must be passed as separate words). In that case, the commands are executed one after the other, serially.

ataraxia wrote:

If you haven't got insight on the particular points I'm asking about, then don't waste your time and mine repeating common knowledge here.

.

Last edited by ron9 (2011-09-11 22:16:38)

ataraxia · 2011-09-12 01:57:50

I apologize to people in this thread who have been giving me the right pointers while I'm being a jerk about it. Even though I do RTFM, apparently I do a bad job at it.

MisterAnderson · 2011-09-12 10:15:41

ataraxia wrote:

I apologize to people in this thread who have been giving me the right pointers while I'm being a jerk about it. Even though I do RTFM, apparently I do a bad job at it.

At least you attempted to find it. If you can't ask questions, then what's the point of understanding?

ngoonee · 2011-09-13 01:21:30

MisterAnderson wrote:

ataraxia wrote:
I apologize to people in this thread who have been giving me the right pointers while I'm being a jerk about it. Even though I do RTFM, apparently I do a bad job at it.
At least you attempted to find it. If you can't ask questions, then what's the point of understanding?

Well, in the same vein of thought, if you can't understand the answers, what's the point of asking questions?

Kudos to ataraxia for the response, though.

MisterAnderson · 2011-09-13 12:00:39

But how do you know you won't understand the answer until you ask the question?

I'm gonna give systemd another go I think. Is there a list of arch packages with systemd units?

tomegun · 2011-09-13 12:09:10

MisterAnderson wrote:

Is there a list of arch packages with systemd units?

On my machine:

% pacman -Ql | grep /lib/systemd/ | awk '{ print $1 }' | uniq
alsa-utils
avahi
bootchart2
consolekit
dbus-core
dnsmasq
initscripts-systemd
libcanberra
lm_sensors
networkmanager
rtkit
systemd
systemd-arch-units
udev

There are plenty of unit files in systemd-arch-units for other packages too. Finally, arch-daemons.target will allow you to start daemons without having unit files (by listing them in DAEMONS in rc.conf).

Arch Linux

#951 2011-09-08 12:58:05

Re: systemd: Yet Another Init Replacement

#952 2011-09-09 03:16:19

Re: systemd: Yet Another Init Replacement

#953 2011-09-09 06:23:55

Re: systemd: Yet Another Init Replacement

#954 2011-09-09 14:02:52

Re: systemd: Yet Another Init Replacement

#955 2011-09-10 01:00:25

Re: systemd: Yet Another Init Replacement

#956 2011-09-10 10:04:00

Re: systemd: Yet Another Init Replacement

#957 2011-09-10 14:35:30

Re: systemd: Yet Another Init Replacement

#958 2011-09-10 15:14:33

Re: systemd: Yet Another Init Replacement

#959 2011-09-10 22:44:25

Re: systemd: Yet Another Init Replacement

#960 2011-09-11 06:56:02

Re: systemd: Yet Another Init Replacement

#961 2011-09-11 08:51:25

Re: systemd: Yet Another Init Replacement

#962 2011-09-11 09:09:37

Re: systemd: Yet Another Init Replacement

#963 2011-09-11 14:32:31

Re: systemd: Yet Another Init Replacement

#964 2011-09-11 14:53:54

Re: systemd: Yet Another Init Replacement

#965 2011-09-11 15:01:19

Re: systemd: Yet Another Init Replacement

#966 2011-09-11 16:12:49

Re: systemd: Yet Another Init Replacement

#967 2011-09-11 16:16:03

Re: systemd: Yet Another Init Replacement

#968 2011-09-11 17:39:53

Re: systemd: Yet Another Init Replacement

#969 2011-09-11 19:08:03

Re: systemd: Yet Another Init Replacement

#970 2011-09-11 22:02:09

Re: systemd: Yet Another Init Replacement

#971 2011-09-12 01:57:50

Re: systemd: Yet Another Init Replacement

#972 2011-09-12 10:15:41

Re: systemd: Yet Another Init Replacement

#973 2011-09-13 01:21:30

Re: systemd: Yet Another Init Replacement

#974 2011-09-13 12:00:39

Re: systemd: Yet Another Init Replacement

#975 2011-09-13 12:09:10

Re: systemd: Yet Another Init Replacement

Board footer