On Wed, 16.05.12 12:07, Colin Guthrie (gm...@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@.service > /etc/lib/systemd/system/getty@.service > /etc/lib/systemd/system/multi-user.target.wants/getty@tty1.service -> > /usr/lib/systemd/system/getty@.service > > I thought that the unit file /etc/lib/systemd/system/getty@.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@.service" and then the normal inheritance rules of > getty@.service resolution apply *after* that, i.e. getty@.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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
