Re: [systemd-devel] Have custom agetty behaviour even after upgadres
'Twas brillig, and Lennart Poettering at 21/05/12 17:37 did gyre and gimble: 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) 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@.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. Hmmm, so what happens if I have: /etc/.../x.target.wants/foo@bar.service - /lib/.../foo@.service /etc/.../x.target.wants/foo@baz.service - /etc/.../foo@.service Which foo@.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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
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
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
'Twas brillig, and Dave Reisner at 14/05/12 22:31 did gyre and gimble: On Mon, May 14, 2012 at 11:01:53PM +0200, Lennart Poettering wrote: On Mon, 14.05.12 14:51, Dave Reisner (d...@falconindy.com) wrote: On Mon, May 14, 2012 at 08:39:23PM +0200, Lennart Poettering wrote: On Thu, 10.05.12 23:27, Seblu (se...@seblu.net) wrote: 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@.service into /etc/systemd/system/ and patched as following: My issue is at every systemd package upgrade, getty@tty1.service is replaced by a new one linked to /usr/lib/systemd/system/getty@.service. And i loose my configuration. This sounds like a packaging problem downstream, nothing we can fix upstream. Strange that you say that, since make install does the following: ( cd $(DESTDIR)$(pkgsysconfdir)/system/getty.target.wants \ rm -f getty@tty1.service \ $(LN_S) $(systemunitdir)/getty@.service getty@tty1.service ) See line 3128ish on git master. This is absolutely something that we (Arch Linux) inherit from upstream. make install is not really too useful for end-user installs, is it? The distro package manager should handle configuration files specially, the way .rpm or .deb do it. I'm saying 'make install' from within the packaging environment with some sort of DESTDIR= variable pointing to the packaging root. Fedora does this, Mageia does this, Arch does this. Anyone who tries to package something this complex on their own is doing it wrong. So are you suggesting that if DESTDIR is set, the /etc/ symlinks should be skipped? I'm not sure I'd vote for DESTDIR dependant stuff - that's just a little bit too cryptic and subtle when working on code for packaging vs working on code for hacking. Personally I'm quite happy with the simple packaging tweak to clean them up: http://svnweb.mageia.org/packages/cauldron/systemd/current/SPECS/systemd.spec?revision=235024view=markup#l256 (s/used/users/ in the comment) 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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
'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@.service into /etc/systemd/system/ and patched as following: --- /usr/lib/systemd/system/getty@.service 2012-05-03 04:37:09.0 +0200 +++ /etc/systemd/system/getty@.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@tty1.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty2.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty3.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty4.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty5.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty6.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty7.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty8.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty9.service - ../getty@.service My issue is at every systemd package upgrade, getty@tty1.service is replaced by a new one linked to /usr/lib/systemd/system/getty@.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@.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. 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/... 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@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/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
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@.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. 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/... 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. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Lennart,
On 14.05.2012 23:34, Lennart Poettering wrote:
I'll bring this closer to home. Why does make
DESTDIR=%{buildroot} install write to $(sysconfdir) when you've
always proclaimed that it's admin territory? Why not write this
link as: $(systemunitdir)/getty.target.wants/getty@tty1.service?
Since this is just about enabling, not about shipping
configuration. People will frequently not enable the getty on tty1,
on servers with serial gettys and on containers for example.
I'd say, leave the entire enabling part to the distro/packager and
don't do the linking at all.
It's up to the distro to decide about a sane default installation with
respect to about every other part of systemd already - why make this
an exception?
- --
Best regards, Wulf
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk+yeo0ACgkQnuVXRcSi+5pffwCeN4nbBuJAu2OmwqA1di3m43d8
db8An0hy4mfbgGsfj6/kbAcdU+WfmkQp
=3lBX
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
On Tue, 15.05.12 17:47, Wulf C. Krueger (philant...@exherbo.org) wrote:
On 14.05.2012 23:34, Lennart Poettering wrote:
I'll bring this closer to home. Why does make
DESTDIR=%{buildroot} install write to $(sysconfdir) when you've
always proclaimed that it's admin territory? Why not write this
link as: $(systemunitdir)/getty.target.wants/getty@tty1.service?
Since this is just about enabling, not about shipping
configuration. People will frequently not enable the getty on tty1,
on servers with serial gettys and on containers for example.
I'd say, leave the entire enabling part to the distro/packager and
don't do the linking at all.
Nah, I am kinda interested in having something that boots sanely after I
do make install.
It's the distro's build scripts job to undo the enabling if this isn't
desired.
It's up to the distro to decide about a sane default installation with
respect to about every other part of systemd already - why make this
an exception?
It is totally up to the distro. Not sure what you mean.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
On Thu, 10.05.12 23:27, Seblu (se...@seblu.net) wrote: 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@.service into /etc/systemd/system/ and patched as following: My issue is at every systemd package upgrade, getty@tty1.service is replaced by a new one linked to /usr/lib/systemd/system/getty@.service. And i loose my configuration. This sounds like a packaging problem downstream, nothing we can fix upstream. I suggested to archlinux maintainer to flag as backup getty@tty1.service to avoid this replacment. But it doesn't seems to be a good solution. Another solution was to remove getty@tty1.service from /etc/systemd/system/ (in arch package). This works with static vt allocation, but when NAutoVTs=0 (default), wihtout this file, there is no tty1 console. It would be sad this is the main expected behaviour. Why with autovt we need this file? because /dev/tty1 is kinda special, and detection of non-usage racy, since we output console output on it. I'm also wondering if we keep in mind the smart hierarchy of /usr/lib/systemd/system, /etc/systemd/system, /run/systemd/system, why this file is not in /usr/lib/systemd/system/getty.target.wants? This would let administrator override it cleanly. Well, on some systems it might make sense to remove the getty on tty1 entirely, i.e. where the primary means of entry is a serial terminal. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
On Mon, May 14, 2012 at 08:39:23PM +0200, Lennart Poettering wrote: On Thu, 10.05.12 23:27, Seblu (se...@seblu.net) wrote: 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@.service into /etc/systemd/system/ and patched as following: My issue is at every systemd package upgrade, getty@tty1.service is replaced by a new one linked to /usr/lib/systemd/system/getty@.service. And i loose my configuration. This sounds like a packaging problem downstream, nothing we can fix upstream. Strange that you say that, since make install does the following: ( cd $(DESTDIR)$(pkgsysconfdir)/system/getty.target.wants \ rm -f getty@tty1.service \ $(LN_S) $(systemunitdir)/getty@.service getty@tty1.service ) See line 3128ish on git master. This is absolutely something that we (Arch Linux) inherit from upstream. d I suggested to archlinux maintainer to flag as backup getty@tty1.service to avoid this replacment. But it doesn't seems to be a good solution. Another solution was to remove getty@tty1.service from /etc/systemd/system/ (in arch package). This works with static vt allocation, but when NAutoVTs=0 (default), wihtout this file, there is no tty1 console. It would be sad this is the main expected behaviour. Why with autovt we need this file? because /dev/tty1 is kinda special, and detection of non-usage racy, since we output console output on it. I'm also wondering if we keep in mind the smart hierarchy of /usr/lib/systemd/system, /etc/systemd/system, /run/systemd/system, why this file is not in /usr/lib/systemd/system/getty.target.wants? This would let administrator override it cleanly. Well, on some systems it might make sense to remove the getty on tty1 entirely, i.e. where the primary means of entry is a serial terminal. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
On Mon, May 14, 2012 at 8:51 PM, Dave Reisner d...@falconindy.com wrote: On Mon, May 14, 2012 at 08:39:23PM +0200, Lennart Poettering wrote: On Thu, 10.05.12 23:27, Seblu (se...@seblu.net) wrote: 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@.service into /etc/systemd/system/ and patched as following: My issue is at every systemd package upgrade, getty@tty1.service is replaced by a new one linked to /usr/lib/systemd/system/getty@.service. And i loose my configuration. This sounds like a packaging problem downstream, nothing we can fix upstream. Strange that you say that, since make install does the following: ( cd $(DESTDIR)$(pkgsysconfdir)/system/getty.target.wants \ rm -f getty@tty1.service \ $(LN_S) $(systemunitdir)/getty@.service getty@tty1.service ) See line 3128ish on git master. This is absolutely something that we (Arch Linux) inherit from upstream. Yeah, make install is different from a package upgrade. The stuff might need to get annotated as noreplace in the package? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
On Mon, May 14, 2012 at 11:01:53PM +0200, Lennart Poettering wrote:
On Mon, 14.05.12 14:51, Dave Reisner (d...@falconindy.com) wrote:
On Mon, May 14, 2012 at 08:39:23PM +0200, Lennart Poettering wrote:
On Thu, 10.05.12 23:27, Seblu (se...@seblu.net) wrote:
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@.service into
/etc/systemd/system/ and patched as following:
My issue is at every systemd package upgrade, getty@tty1.service is
replaced by a new one linked to
/usr/lib/systemd/system/getty@.service.
And i loose my configuration.
This sounds like a packaging problem downstream, nothing we can fix
upstream.
Strange that you say that, since make install does the following:
( cd $(DESTDIR)$(pkgsysconfdir)/system/getty.target.wants \
rm -f getty@tty1.service \
$(LN_S) $(systemunitdir)/getty@.service getty@tty1.service )
See line 3128ish on git master. This is absolutely something that we (Arch
Linux) inherit from upstream.
make install is not really too useful for end-user installs, is it?
The distro package manager should handle configuration files specially,
the way .rpm or .deb do it.
I'm saying 'make install' from within the packaging environment with
some sort of DESTDIR= variable pointing to the packaging root. Fedora
does this, Mageia does this, Arch does this. Anyone who tries to package
something this complex on their own is doing it wrong.
I'll bring this closer to home. Why does make DESTDIR=%{buildroot} install
write to $(sysconfdir) when you've always proclaimed that it's admin territory?
Why not write this link as:
$(systemunitdir)/getty.target.wants/getty@tty1.service?
d
This is not a problem exclusive to systenmd. All automake based packages
overwrite configuration files on make install, and expect the package
manager to handle this more nicely if the simple an brutal scheme is not
sufficient...
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have custom agetty behaviour even after upgadres
On Mon, 14.05.12 17:31, Dave Reisner (d...@falconindy.com) wrote:
See line 3128ish on git master. This is absolutely something that we (Arch
Linux) inherit from upstream.
make install is not really too useful for end-user installs, is it?
The distro package manager should handle configuration files specially,
the way .rpm or .deb do it.
I'm saying 'make install' from within the packaging environment with
some sort of DESTDIR= variable pointing to the packaging root. Fedora
does this, Mageia does this, Arch does this. Anyone who tries to package
something this complex on their own is doing it wrong.
Yupp, absolutely, but the tool which then copies the stuff from DESTDIR
to the real root should handle the overriding of the file in question
properly.
I'll bring this closer to home. Why does make DESTDIR=%{buildroot} install
write to $(sysconfdir) when you've always proclaimed that it's admin
territory?
Why not write this link as:
$(systemunitdir)/getty.target.wants/getty@tty1.service?
Since this is just about enabling, not about shipping
configuration. People will frequently not enable the getty on tty1, on
servers with serial gettys and on containers for example.
We make a suggestion to enable the getty for tty1, but we don't think it
it should stay enabled even if the user disables it in /etc.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Have custom agetty behaviour even after upgadres
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@.service into /etc/systemd/system/ and patched as following: --- /usr/lib/systemd/system/getty@.service 2012-05-03 04:37:09.0 +0200 +++ /etc/systemd/system/getty@.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@tty1.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty2.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty3.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty4.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty5.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty6.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty7.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty8.service - ../getty@.service lrwxrwxrwx 1 root root 17 2012-03-12 22:40 getty@tty9.service - ../getty@.service My issue is at every systemd package upgrade, getty@tty1.service is replaced by a new one linked to /usr/lib/systemd/system/getty@.service. And i loose my configuration. I suggested to archlinux maintainer to flag as backup getty@tty1.service to avoid this replacment. But it doesn't seems to be a good solution. Another solution was to remove getty@tty1.service from /etc/systemd/system/ (in arch package). This works with static vt allocation, but when NAutoVTs=0 (default), wihtout this file, there is no tty1 console. It would be sad this is the main expected behaviour. Why with autovt we need this file? I'm also wondering if we keep in mind the smart hierarchy of /usr/lib/systemd/system, /etc/systemd/system, /run/systemd/system, why this file is not in /usr/lib/systemd/system/getty.target.wants? This would let administrator override it cleanly. Regards, -- Sébastien Luttringer https://www.seblu.net ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
