[systemd-devel] persistent changes to the serial console

[Zbigniew Jędrzejewski-Szmek]

On Sun, Mar 31, 2013 at 12:30:05PM +0400, Andrey Borzenkov wrote:
> В 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.
Seems to be the most sensible choice. Easier to explain than having a
link with a destination which doesn't matter (unless it's /dev/null,
or points outside the normal tree of units, or ...). touch is also a
tad easier to invoke for the admin than ln.

Zbyszek