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

[Lennart Poettering]

On Do, 16.05.19 12:04, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) wrote:

> > This is explained in the documentation btw:
> > https://www.freedesktop.org/software/systemd/man/systemd.generator.html
> >
> > Long story short: it's about unit file precedence.
>
> Sorry I don't get it: So the idea is to have different generators, depending
> on the precedence?

No. As explained in the documentation: sometimes you want to generate
dynamic unit files that override the regular unit files (think:
overriding the boot target the system shall boot into). Sometimes you
want that regular unit files override the dynamic ones (think: you
automaticlly convert sysv scripts to native unit files, but if a
regular unit file already exists for a service you want that to take
precedence, since native should be better than converted).

All generators are run at the same time btw, there's no ordering
between them.

> >> How should it know? Wouldn't it be easier to provide one path and
> >> adjust that as necessary? (My generator just uses the first path)
> >
> > It's up to the generator to decide whether it wants to override native
> > unit files already in place, or whether it wants those to override
> > whatever it generates.
>
> OK, so different generators.

Nope, please read the documentation. it's very clearly explained
there. It's about precendence relative to installed regular unit files.

> > Please read up on the documentation.
>
> Actually I have read it multiple times, but still is's not very
> helpful.

Sorry, but it doesn't appear like you did...

> Is calling the generators logged (and maybe finishing the last generator,
> too)? After boot I could not find a journal message regarding that.

Turn on debug logging, and it is. i.e. add systemd.log_level=debug to
the kernel command line.

> > Doing "systemctl daemon‑reload" in clean codepaths is possible but not
> > good style. It's slow and problematic since Linux doesn't really have
> > a transactional fs, and thus you never know in which precise state the
> > fs is when systemd reloads things in case multiple programs make
> > modifications to the unit files at the same time.
>
> So what is the preferred method when some package install adds new
> unit files?  systemctl daemon-reload?

Yes. That's the command to invoke whenever you remove or drop in unit
files into the directories in /usr/lib/systemd/system or
/etc/systemd/system or similar.

> >> What makes your generators special? That they have no explicitly
> >> settable dependencies, or that they are called with three directory
> >> arguments?
> >
> > I am not sure how to parse that.
>
> You claim the generators are very special, but I don't get
> it. Sorry.

They run in an early boot environment outside of any service
management, snce they generate service definitions. That makes them
kinda special. See the long list of dos/donts in the documentation.

https://www.freedesktop.org/software/systemd/man/systemd.generator.html

> > As I mentioned before: you appear to think that generators are
> > something they are clearly not.
>
> And you seem unable to explain why they are not what I thing they
> are.

I am sorry, but this gets on my nerves. Yes, our documentation is not
perfect (which documentation is?) but you appear unable to read even
the most basic parts of it, since most of what you are asking is
actually documented in the various linked docs.

Please, when you are new to systemd, start with the simple things
first, and as you grokked them continue with the more complex
stuff. You are jumping to the advanced stuff from zero apparently,
without understanding the basic concepts the advanced stuff builds
on. Of course things are going to be frustrating if you do that, but
maybe the fix to that is starting to reading up on the basics first!

You receieved an awful lot of free help here even though when you came
onto the mailing list you started out with telling evreyone how awful
systemd is. You are using up all my patience slowly but surely, and if
you continue like that you'll notice the responses you get will be
fewer and fewer.

> And what creates those dependency links and when? It's OK to point me to the
> correct manual page.

For units installed via packages in /usr/lib/systemd/system or by the
user in /etc/systemd/system these links are created by "systemctl
enable". You can also create them maualy if you like, that's fine.

That maps 1:1: how tools such as update-rc.d or chkconfig did things
on the various distros back in sysvinit times.

If you write a generator then its the generator that creates the
symlinks. But again, generators are an advanced topic, and you
shouldn't use them unless you really really know what you are doing.

https://www.freedesktop.org/software/systemd/man/systemctl.html#enable%20UNIT%E2%80%A6

> > the right places. systemctl can't guess that. I mean, if a service
>
> So "link messing"; it's the ugly part of systemd.

What's so hard about using "systemctl enable"? I mean, you explicitly
decided to do the link stuff manually, so how can you complain about
that?

> > shall be started during regular boot, or if it shall be hooked into
> > getty.target or when bluetooth hw is plugged in is nothing systemd can
> > guess for you.
>
> Isn't it sufficient when a generated unit contains "Wants=" or similar? If I
> have to mess with links, why does "Wants=" exist at all? Maybe its all
> historical, I don't know.

If you have a unit A that shall pull in B then you can edit A and add
Wants=B into it and evreything is fine. But sometimes you can't really
do that, because A is supplied by the OS vendor (for example:
multi-user.target is one of those that often is used by 3rd part units
because they want to be started whenever multi-user.target is
requested) and thus editing sucks because you would cut it off from
the usual upstream update cycles. So what you do instead is place a
symlink in a .wants/ directory next to it, and thus slightly extend
the unit file, without actually changing it. systemd then reads both
the unit file and the items in the .wants/ directory and merges all
together.

Lennart

--
Lennart Poettering, Berlin