On Wed, May 15, 2019 at 9:01 AM Ulrich Windl
wrote:
>
> >>> Andrei Borzenkov schrieb am 14.05.2019 um 20:21 in
> Nachricht :
> > 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@.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".
> 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.
> >
> > 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.
> 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.
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.
> 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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
