[systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?
Ulrich.Windl at rz.uni-regensburg.de
Wed May 15 10:01:36 UTC 2019
>>> Lennart Poettering <lennart at poettering.net> schrieb am 15.05.2019 um 11:54
Nachricht <20190515095443.GA22887 at gardel-login>:
> On Mi, 15.05.19 12:47, Andrei Borzenkov (arvidjaar at gmail.com) wrote:
>> > > localhost:~ # systemctl enable usr‑local.mount
>> > > Failed to enable unit: Unit /run/systemd/generator/usr‑local.mount is
>> > > transient or generated.
>> > > localhost:~ # exit
>> > Hmm?
>> > No? Why?
>> You just said that "You should never need to. [mess with symlinks].
>> For all relevant operations there are "systemctl"".
> Yeah, for all user‑facing operations.
> Writing a generator is not a typical user would do. It's what a
> developer of a package would do, and yes, in that case, when you write
> code you need a bit more understanding of the underpinnings and need
> to do more work.
systemd.generator(7) could really need some (better/realistic) examples.
>> > generated units cannot be enabled, what am I missing?
>> You are apparently missing context to which you replied. This
>> discussion *is* about enabling generated units. Of course, we now
>> again have problem that everyone implies different meaning of
>> "enabled". To avoid this word altogether ‑ generated unit can only be
>> included in initial transaction if it is dependency of some other unit
>> (already included in original transaction). You just claimed that to
>> establish such dependency one should use systemctl and I demonstrated
>> that this does not work. Either your claim is wrong, or the observed
>> behavior is a bug.
> Again, generators are written by developers, not regular users doing
> day‑to‑day work. They assumed to be enabled as the developers intend
> them to, and that's orthogonal to the manual enable/disable scheme
> that applies to regular, package‑shipped, file‑based units...
> Lennart Poettering, Berlin
More information about the systemd-devel