[systemd-devel] persistent changes to the serial console

[Lennart Poettering]

On Sat, 30.03.13 11:34, Colin Guthrie (gmane at colin.guthr.ie) wrote:

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

Hmm, I did? Doesn't make much sense to me though, at least now ;-)

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

Well, it does matter, but only as last file we look for. So we will add
the actual symlink to the files we search for, but we will always look
for overriding files and follow the symlink only last. This is pretty
much irrelevant though unless you link a unit file that resides outside
of the usual search path into the search path.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.