On Mon, Mar 7, 2011 at 4:00 AM, Lennart Poettering <lenn...@poettering.net> wrote: > On Fri, 04.03.11 14:51, Bill Nottingham (nott...@redhat.com) wrote: > >> The implementation of the is-enabled command makes its not necessarily >> useful as I might expect it to be. From looking at it, it merely checks >> whether the '[Install]' section has been executed. > > That is true. > >> That means that it's not going to be correct for any service that has >> been enabled via other means, or doesn't have an '[Install]' section. > > For the latter we generate a warning currently, telling the user that > the service has no [Install] section. > >> Am I missing something? Is there a different command that should be used? >> It seems a more full implementation would parse the dependency graph for >> either the current or given target, and check that the service is wanted >> by some part of that. > > Well, but what is the "current" target? We can have multiple. >
Well, "currently isolated target" - is it good enough? This is close enough approximation to run-levels we had before. > And if you boot into single user mode, you probably are still interested > to know whether a service is enabled in multi-user.target when [Install] > says so. > Yes, that is what --level option in chkconfig is for. Actually this could be conceivable for systemctl as well - systemctl is-enabled --target=multi-user.target? > Or to turn this around: I don't think "is-enabled" should have > different results when you run it from a different state of the system > or from a chroot or wherever. > If definition of "is-enabled" is "whether stanzas in [Install] section were applied" - I completely agree. The question is - what is intended usage of it? > What about this solution consisting of these 4 rules together: > > 1. A service residing in /lib with no [Install] section will > unconditionally be considered enabled. > 2. A service which has at least one symlink to it in /etc is considered > enabled. > 3. Symlinks in /lib are irrelevant > 4. We'd not recursively traverse tree > > That way dbus would always appear enabled due to rule #1. > > Does that make sense? > I think it depends on intended usage. I think current semantic could be used as light weight replacement of "chkconfig service" where needed; although question again is - when would such query be needed? More close match to chkconfig would probably be "will this service be part of transaction to isolate specific target". This actually is pretty useful by itself :) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
