On Mi, 15.05.19 10:14, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >> >> 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?

The string shown on your version is a bug. Please ask your distro to
backport the fix for that, which has been merged upstream many years

> > 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...

You should never need to. For all relevant operations there are
"systemctl" verbs, i.e. "systemctl enable", "systemctl disable",
"systemctl add-wants" and so on.

Note that the symlink stuff is inherited directly from sysvinit in
fact, where services where enabled/disabled via symlinks int
/etc/rc.d/ too.

But again, the fact that these are symlinks is something you can
ignore if you want to, just use the relevant systemctl commands

> 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.

It never has to. A generated unit is shown as "generated" in all
systemd versions from the last few years in fact. Please ask your
distro to backport this.


Lennart Poettering, Berlin
systemd-devel mailing list

Reply via email to