[systemd-devel] Antw: Re: Re: "bad" status for genersated target; why?

[Ulrich Windl]

>>> Andrei Borzenkov <arvidjaar at gmail.com> schrieb am 15.05.2019 um 09:21 in
Nachricht
<CAA91j0WPzJ0RE02EviqS9rrxuxT_z4JZP_uzd6C54+dxKYry1Q at mail.gmail.com>:
> On Wed, May 15, 2019 at 9:01 AM Ulrich Windl
> <Ulrich.Windl at rz.uni-regensburg.de> wrote:
>>
>> >>> Andrei Borzenkov <arvidjaar at gmail.com> schrieb am 14.05.2019 um 20:21
in
>> Nachricht <c39c1270-41bf-dd7a-ed39-11c148f336a9 at gmail.com>:
>> > 14.05.2019 16:39, Ulrich Windl пишет:
>> >> Hi!
>> >>
>> >> Developing my first systemd service I have some problems I don't
>> understand:
>> >> After installation, I get this status:
>> >> # systemctl status iotwatch.target          ● iotwatch.target -
iotwatch
>> I/O
>> >> performance monitor
>> >>    Loaded: loaded (/run/systemd/generator.late/iotwatch.target; bad;
>> vendor
>> >> preset: disabled)
>> >>    Active: inactive (dead)
>> >>      Docs: man:iotwatch at .service(8)
>> >>            man:iotwatch-generator(8)
>> >>
>> >> Why "bad"?
>> >
>> > Again - this has improved in current version which now tells you that
>> > unit is generated.
>>
>> So there's nothing wrong with the unit?
>>
>> >
>> >> # ll /run/systemd/generator.late/iotwatch.target
>> >> -rw-r--r-- 1 root root 281 May 14 15:24
>> >> /run/systemd/generator.late/iotwatch.target
>> >> # systemctl is-enabled iotwatch.target
>> >> Failed to get unit file state for iotwatch.target: No such file or
>> directory
>> >>
>> >> Here we are again: Where should the file be?
>> >> Aren't targets allowed to be generated?
>> >>
>> >
>> > Targets are allowed to be generated but generated units cannot be
>> > enabled/disabled. The rationale probably is that if you create unit file
>> > you can just as well create symlink to this unit file. Also "systemctl
>>
>> I think "Generated iotwatch.target cannot have a state" would be a much
>> improved error message then.
> 
> Define "state".

enabled|disabled

> 
>> So again there's nothing wrong with the unit
>> file?
>>
>> > dameon-reload" removes and re-creates all generated units, so any
>> > symlink to such unit outside of generated subdirectories potentially
>> > becomes invalid.
>>
>> I think all the symlink stuff should be an implementation detail that
>> shouldn't be part of the user interface; instead there should be some
>> higher-level commands to maipulate these.
>>
> 
> It is exactly the opposite - symlinks are *the* official documented
> method to configure unit dependencies; "systemctl enable" is just
> convenience layer on top of it.

To me it's the most horrible part of systemd: Messing with symlinks...

> 
>> >
>> > Documentation could be better indeed.
>>
>> Finally: If a generated unit cannot be enabled or disabled, isn't the
>> "vendor-preset: disabled" the wrong choice:
> 
> Neither is it printed in current systemd version.

OK, good.

> 
>> I specified nothing, and the logic
>> should be: If a generator created a unit it should be enabled; otherwise 
> sich a
>> unit shouldn't be enabled.
>>
> 
> You misinterpret "enabled" and "disabled" basing on their English
> meaning. Unit is "enabled" if links specified in [Install] sections
> are present. Nothing more nothing less. You apparently assume
> "enabled" means something different.

To me "enabled" means "it'll be started on boot" (or other events) and
"stopped on shutdown". "disabled" means the opposite. Quite simple.


> 
> Generators run immediately before systemd computes initial
> transaction; there is no point in time when user could perform
> "systemctl enable" on them - it is already too late, system is already
> booted using whatever configuration (including generated units) was
> present. So any required links really have to be created together with
> generated unit itself.

My point was: Once  a generator generates a target, it should be "enabled"
(see above), I don't see why I (or a program) should have to mess with symbolic
links.

> 
>> I couldn't find the relevant manual page that discusses this topic...
>>
> 
> Yes, the fact that generated units apparently cannot be
> enabled/disabled using systemctl is not documented anywhere. Still
> current systemd gives quite precise error message when you are trying
> to do it. But documentation could certainly be improved.

The problem is you don't know where to start reading, like finding your way in
those old dungeon adventures...

Regards,
Ulrich