On Wed, 23.02.11 17:38, Toshio Kuratomi (a.badger@xxxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
