On Thu, Feb 24, 2011 at 02:23:06PM +0100, Lennart Poettering wrote:
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:
> 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.
Runlevels belong here since system administrators are coming from a system
that uses them and need to know how to transition into the new world.
Dropping that would defeat the purpose of the page. I've added some more
text to the page to try to get them thinking more about some of the new
possibilities that the transition offers them without going overboard and
making it no longer a cheatsheet.
> 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.
Thanks. Good to know that part is correct.