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

[Lennart Poettering]

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)

> 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.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.