[systemd-devel] systemctl is-enabled...

[Andrey Borzenkov]

On Mon, Mar 7, 2011 at 4:00 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Fri, 04.03.11 14:51, Bill Nottingham (notting at 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 :)