On Thu, Feb 24, 2011 at 02:23:06PM +0100, Lennart Poettering wrote: > 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. > 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. -Toshio
Attachment:
pgpzNTV0yL18a.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
