SysVinit to Systemd cheatsheet change.. can someone verify it's right?
mzerqung at 0pointer.de
Thu Feb 24 13:23:06 UTC 2011
On Wed, 23.02.11 17:38, Toshio Kuratomi (a.badger at gmail.com) wrote:
> I just made a couple changes to the first table of this page:
> The chkconfig frozbozz --levels 345 on line listed systemctl enable
> frozbozz.service as the main equivalent. From running that command on
> rawhide, that doesn't seem to be correct. enable made the service active in
> the targets that were listed in the services unit file (in the WantedBy=
> line). It didn't have anything to do with the runlevels that the system
> administrator was specifying (345).
Uh. This should be dropped entirely. In systemd the classic SysV
runlevels exists only as compatibility aliases and they do have
different semantics: unless you go and reconfigure things non-trivially
runlevel 5 (graphical.target) will always be a superset of runlevel 3
(multi-user.target). And runlevel 2 and runlevel 4 will always be
synonyms of 3. Hence it makes little sense to enable something in
runlevel "3 and 4", since that will actually just enable it in
multi-user.target and that's it.
On top of that one shouldn't limit ones focus to the equivalents of
runlevels. In systemd things are a lot more flexible. For example
instead of hooking yourself into "multi-user.target" you could hook your
stuff into "bluetooth.target" which is activated as soon as bt hw is
around. bluez is now activated like this.
I don't think runlevels should appear on the cheat sheet here.
> The second change is that the "manual" method specified there was using
> ln -s ../frobozz.service /lib/systemd/system/runlevel3.target.wants/
> This seems to be incorrect since it's touching /lib instead of /etc. /etc
> would both be the proper FHS place to do this (/lib and /etc could be on
> separate partitions with different read-write permissions in FHS and /etc
> might be backed up while /lib would not by a sysadmin that thinks the system
> adheres to the FHS) and it seems to be where the systemctl enable command
> puts the symlinks as well.
Yes, as mentioned elsewhere, in systemd /etc/systemd/system is admin
territory, and /lib/systemd/system is packager territory. The former
always overrides the latter. If and admin wants to edit a service file he
should copy it from /lib/systemd/system to /etc/systemd/system and edit
it there. Then the package manager will never muck with it. Similarly,
.wants/ links should be placed in /etc, too.
Lennart Poettering - Red Hat, Inc.
More information about the devel