On Tue, Sep 21, 2010 at 00:20, Lennart Poettering <lenn...@poettering.net> wrote: > On Sat, 18.09.10 21:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > >> Let's assume unit foo is installed as wanted by other unit under >> $systemunitdir (/lib/systemd/system/bar.wants/foo). How can I now >> disable it? systemctl (enable|disable) only manipulates links under >> $pkgsysconfdir, so "systemctl disable foo" in this case does nothing. >> >> Such links are created during standard installation of systemd. > > Services enabled via /lib/systemd/system/xxxx.wants/ are not intended to > be disabled by the user/admin. > > The idea is that we link only those services in /etc/systemd/system > where the admin/user has a good reason to disable them. However all > really basic services that are integral part of the OS are symlinked > directly in /lib/systemd/system, thus offering less of a chance for > breakage and making things less fragile. > > Speaking with an example: the admin/user might have a good reason to > enable/disable an installed apache, but there's little point in > disabling/enabling really basic services such as hwclock.service, which > we hence pull in unconditionally, > > If some distros decide to disable these services nonetheless, then they > can do that by doing "rm" after the "make install". But disabling those > services should be left to the distros, not the admin/user. > > The line between those services which are enabled via /etc and those > enabled via /lib is the same line which seperates stuff that is supposed > to be under admin/user control from stuff under OS developer control.
You can also link the service to /dev/null in /etc, it will overwrite all stuff in /lib, just like the udev rules work. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
