[systemd-devel] Have custom agetty behaviour even after upgadres

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 21/05/12 17:37 did gyre and gimble:
> On Wed, 16.05.12 12:07, Colin Guthrie (gmane at colin.guthr.ie) wrote:
> 
>> I thought that the actual end point of the symlink was not all that
>> important...
>>
>> e.g. if I have:
>>
>> /usr/lib/systemd/system/getty at .service
>> /etc/lib/systemd/system/getty at .service
>> /etc/lib/systemd/system/multi-user.target.wants/getty at tty1.service ->
>> /usr/lib/systemd/system/getty at .service
>>
>> I thought that the unit file /etc/lib/systemd/system/getty at .service was
>> still the one used. i.e. the symlink is merely indicative of whether the
>> service is enabled or not, and the actual physical file that it points
>> to is not relevant.
> 
> This is not correct. The destination is important. The algorithm works
> like this: we traverse the chain of symlinks and add all their names as
> alias names to the unit and load the final unit file as source and use
> its name as "main" name of the unit file.
> 
> (OK, it's a bit more complicated, since when there is a non-instaniated
> unit name in one of the symlink/filenames we implicitly instantiate it
> as necessary)

This logic would suggest that I cannot override any units that are
enabled statically via a .wants symlink in /lib/... tree. Is that
correct? (or does your comment above only apply to template unit names?)

>> i.e. The .wants symlink only really states "I'm enabled as an instance
>> of getty at .service" and then the normal inheritance rules of
>> getty at .service resolution apply *after* that, i.e. getty at .service in
>> /etc/... overrides the one in /lib/...
> 
> When looking for a unit file we first look for the instance, and follow
> the symlinks there, and if that was not sucessful we look for the
> template doing the same.


Hmmm, so what happens if I have:

/etc/.../x.target.wants/foo at bar.service -> /lib/.../foo at .service
/etc/.../x.target.wants/foo at baz.service -> /etc/.../foo at .service

Which foo at .service unit is actually used? Will there be two distinct
units loaded in memory and each instantiation uses the right one?

Or will they both get the /etc one? Or maybe both get the /lib one? Or
maybe it's random?

Can you maybe also comment on Michal's reply in this thread too where he
comments that he considers this behaviour a bug? It would be nice if you
could agree on how things should work :)


Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/