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

Colin Guthrie gmane at colin.guthr.ie
Wed May 16 07:20:53 PDT 2012


'Twas brillig, and Michal Schmidt at 16/05/12 12:51 did gyre and gimble:
> On 05/16/2012 01:07 PM, Colin Guthrie wrote:
>> This thread went a little tangential, so I'd like to bring it back to
>> the "problem" stated here.
>>
>> Firstly, that was not my understanding of how things are supposed to
>> work, but perhaps Lennart or Kay can clarify.
>>
>> 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.
>>
>> 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/...
>>
>> This is maybe not intuitive when looking solely at the symlinks
>> themselves, but it is when you think about what they represent.
> 
> Colin,
> 
> your description matches my understanding. In my test it works as
> expected with ordinary units, but not if templates are involved.
> I consider it a bug.

Ahhh right. Yeah I would consider that a bug too if the same logic does
not apply to template units as with regular ones.

Thanks for the clarifications.

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/



More information about the systemd-devel mailing list