[systemd-devel] persistent changes to the serial console

[Andrey Borzenkov]

В Sat, 30 Mar 2013 11:34:08 +0000
Colin Guthrie <gmane at colin.guthr.ie> пишет:

> 'Twas brillig, and Lennart Poettering at 29/03/13 15:32 did gyre and gimble:
> > On Fri, 29.03.13 13:29, Andrey Borzenkov (arvidjaar at gmail.com) wrote:
> > 
> >> serial-getty at .service is used only as template, and it looks like
> >> getty-generator always links to (/usr)/lib/systemd:
> >>
> >>         from = strappend(SYSTEM_DATA_UNIT_PATH "/", fservice);
> >>         to = strjoin(arg_dest,"/getty.target.wants/", tservice, NULL);
> >>
> >> It probably should use real unit path for fservice.
> > 
> > Hmm, so actually even if you symlink like this, then /etc should
> > override /lib, and the symlink destination path should only be used as
> > last fallback. That's at least the theory, but there might be a bug
> > somewhere... iirc there where problems with that, where aliases of
> > autvt@ didn't get taken into account properly either... Something to
> > look into definitely. Added to TODO list.
> 
> Hmm, is this changed behaviour from the past.
> 
> I remember you explaining to me a while back that templated units follow
> the symlink and use that unit definition, unlike regular units which
> just check the unit name. Didn't really ever like that logic, but such
> was the way of things.
> 

As far as I can tell, this is what happens currently. If we have *file*
with name foo at bar.service it will try to open this file (following
symlinks etc but it is irrelevant here). It will not strip instance
name and try to lookup template unit. So whatever foo at bar.service is
linked to wins.

This looks different for "on-the-fly" instantiation, when on-disk
instance file does not exist. Then we indeed fall back to looking up
template unit following standard rules.

Which leads to problem in this thread. 

I do not know whether this is intentional. But this is more or less
consistent. We follow priority rules to select unit definition *file*
but as long as file is found we use it. It would be highly confusing to
have foo at bar.service linked to /usr/lib/systemd/system/foo at .service but
in reality using completely different definition from /etc/systemd.

So I still believe that it is generator that has to be fixed. But it
does not look like it is possible to fetch template name:

bor at opensuse:~/src/systemd/src> systemctl --no-pager show getty at .service
Failed to issue method call: Unit name getty at .service is not valid.

So combining it with next paragraph ...

> What you say above seems to suggest that in all cases the actual
> destination of the symlink doesn't matter at all, it's purely the unit
> name that counts. Is that the case?
> 

In this case why do we need *link* in .wants and .requires directories
at all? This leads to the same weird pathname resolution issues. Why not
simply do

touch .../some.target.wants/foo at bar.service

and let it load foo at bar.service by name using standard search order?
This makes it obvious that content of .wants and .requires is just name
labels, while using symlink implies that it is file content that is
used.