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

Colin Guthrie gmane at colin.guthr.ie
Wed May 16 04:07:09 PDT 2012


'Twas brillig, and Seblu at 10/05/12 22:27 did gyre and gimble:
> Hello,
> 
> on my archlinux test computer i would have first console not cleaned
> and other spawned statically (crazy idea isn't it).
> 
> So I've turned NAutoVTs to 1 in /etc/systemd/systemd-logind.conf.
> I've copied /usr/lib/systemd/system/getty at .service into
> /etc/systemd/system/ and patched as following:
> 
> --- /usr/lib/systemd/system/getty at .service      2012-05-03
> 04:37:09.000000000 +0200
> +++ /etc/systemd/system/getty at .service  2012-04-16 01:11:52.046979314 +0200
> @@ -18,14 +18,14 @@
> 
>  [Service]
>  Environment=TERM=linux
> -ExecStart=-/sbin/agetty %I 38400
> +ExecStart=-/sbin/agetty --noclear %I 38400
>  Restart=always
>  RestartSec=0
>  UtmpIdentifier=%I
>  TTYPath=/dev/%I
> -TTYReset=yes
> -TTYVHangup=yes
> -TTYVTDisallocate=yes
> +TTYReset=no
> +TTYVHangup=no
> +TTYVTDisallocate=no
>  KillMode=process
>  IgnoreSIGPIPE=no
> 
> After this i've symlink all my gettys in
> /etc/systemd/system/getty.target.wants
> # cd /etc/systemd/system/getty.target.wants
> # ls -l
> total 0
> lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty at tty1.service ->
> ../getty at .service
> lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty at tty2.service ->
> ../getty at .service
> lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty at tty3.service ->
> ../getty at .service
> lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty at tty4.service ->
> ../getty at .service
> lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty at tty5.service ->
> ../getty at .service
> lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty at tty6.service ->
> ../getty at .service
> lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty at tty7.service ->
> ../getty at .service
> lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty at tty8.service ->
> ../getty at .service
> lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty at tty9.service ->
> ../getty at .service
> 
> My issue is at every systemd package upgrade, getty at tty1.service is
> replaced by a new one linked to
> /usr/lib/systemd/system/getty at .service.
> And i loose my configuration.

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.

I've not actually poked at the code or tried this out, but that's always
been my understanding.

If this is the case, it shouldn't matter that your getty at tty1.service is
linked to the "wrong" unit file and your config should be preserved.



If I'm wrong here (entirely possible) perhaps Lennart or Kay could
explain why this is useful behaviour to allow the wants symlinks'
destination file to take precedence over the administrators own units?


Cheers

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