On Sun, Mar 31, 2013 at 12:30:05PM +0400, Andrey Borzenkov wrote: > В Sat, 30 Mar 2013 11:34:08 +0000 > Colin Guthrie <[email protected]> пишет: > > > 'Twas brillig, and Lennart Poettering at 29/03/13 15:32 did gyre and gimble: > > > On Fri, 29.03.13 13:29, Andrey Borzenkov ([email protected]) wrote: > > > > > >> [email protected] 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 [email protected] 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 [email protected] 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 [email protected] linked to /usr/lib/systemd/system/[email protected] 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@opensuse:~/src/systemd/src> systemctl --no-pager show [email protected] > Failed to issue method call: Unit name [email protected] 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/[email protected] > > and let it load [email protected] 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
