On Wed, 23.02.11 17:38, Toshio Kuratomi (a.badger(a)gmail.com) wrote:
I just made a couple changes to the first table of this page:
https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet#Services
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
--
Lennart Poettering - Red Hat, Inc.