On Wed, May 15, 2019 at 9:01 AM Ulrich Windl
> >>> 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
> >> After installation, I get this status:
> >> # systemctl status iotwatch.target ● iotwatch.target - iotwatch
> >> performance monitor
> >>Loaded: loaded (/run/systemd/generator.late/iotwatch.target; bad;
> >> preset: disabled)
> >>Active: inactive (dead)
> >> Docs: man:iotwatch@.service(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
> >> 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.
> So again there's nothing wrong with the unit
> > 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
> 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