On Sun, Mar 31, 2013 at 12:30:05PM +0400, Andrey Borzenkov wrote: > В Sat, 30 Mar 2013 11:34:08 +0000 > Colin Guthrie <gm...@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 (arvidj...@gmail.com) wrote: > > > > > >> serial-getty@.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@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@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@bar.service linked to /usr/lib/systemd/system/foo@.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@opensuse:~/src/systemd/src> systemctl --no-pager show getty@.service > Failed to issue method call: Unit name getty@.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@bar.service > > and let it load foo@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
