Subject: Starts 2nd getty on hvc0, making console login (almost) impossible
Date: Mon, 14 Apr 2025 16:28:36 +0200
Package: getty-run
Version: 2.2.0-2
Severity: critical
Justification: makes console logins all but impossible, thus arguably breaking the entire system
Hi,
I have a VPS that's a domU guest, so its console is /dev/hvc0.
I had my own getty service on it, called getty-hvc0.
During a dist-upgrade, the getty-run package was pulled in, and a(n IMO misleadingly named) getty-ttyS0 service enabled by default.
This system doesn't have a /dev/ttyS0, but that doesn't stop the getty-ttyS0 service from doing this:
--- 8< ---
root /etc/sv/getty-ttyS0 # sh -xveu ./run
#!/usr/bin/env /lib/runit/invoke-run
# get device from kernel command line, override ./env/SGETTY
if grep 'console=' /proc/cmdline ; then
kconsole=$(grep -o '\bconsole=[^ ]*' /proc/cmdline)
#TODO: only a subset of this parameter is supported: no uart[8250]/brl, no options
#full format: see https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
kconsole=${kconsole##*=} #only the last one matches, the kernel writes there
SGETTY=${kconsole%,*} #discard options if any
[ "$SGETTY" = 'null' ] && SGETTY="" #discard null
fi
+ grep console= /proc/cmdline
root=[...] root=/dev/xvda1 console=hvc0 [...]
+ grep -o \bconsole=[^ ]* /proc/cmdline
+ kconsole=console=hvc0
console=hvc0
+ kconsole=hvc0
+ SGETTY=hvc0
+ [ hvc0 = null ]
#don't change here, edit ./env/SGETTY instead
#example: echo ttyS1 > /etc/sv/getty-ttyS0/env/SGETTY
[ -z "$SGETTY" ] && SGETTY=ttyS0
+ [ -z hvc0 ]
if ! test -c /dev/"$SGETTY" ; then
sv d getty-ttyS0
echo "/dev/$SGETTY not found: stopping getty-ttyS0"
fi
+ test -c /dev/hvc0
if pgrep -x agetty -t "$SGETTY" || pgrep -x fgetty -t "$SGETTY"; then
sv d getty-ttyS0
echo "already another getty on $SGETTY: stopping getty-ttyS0"
fi
+ pgrep -x agetty -t hvc0
+ pgrep -x fgetty -t hvc0
exec 1>&2
+ exec
if [ -e /sbin/fgetty ]; then
exec chpst -P fgetty /dev/"$SGETTY"
else
exec /sbin/getty -L "$SGETTY" 9600 vt100
fi
+ [ -e /sbin/fgetty ]
+ exec /sbin/getty -L hvc0 9600 vt100
--- >8 ---
Since I already had a getty on hvc0, the two gettys ended up fighting over the console input, making it *very tricky* to log in successfully.
If you think you must go and enable services unconditionally by default, please somehow make sure this doesn't happen; for example, add something like this:
if fuser -v "$SGETTY" 2>&1 | grep -q getty; then exec sleep 3600; fi
(Not perfect, but it would have helped me at least.)
(Also, unrelated, but not worth its own bugreport:
1. if /dev/$SGETTY is not found, you stop the service; but maybe the getty will appear later, for example when a module is loaded, or a device is (re)connected to the system.
2. you hardwired the name of the service into the script. I think it would be better to do "exec sv d ." to stop the service, whatever it may be called, as the last action, similar how you'd use "exit" in a plain shell script.)
András
-- System Information:
Debian Release: trixie/sid
APT prefers stable-security
APT policy: (500, 'stable-security'), (350, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.12.20-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=hu_HU.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled
Versions of packages getty-run depends on:
ii runit-helper 2.16.4
getty-run recommends no packages.
Versions of packages getty-run suggests:
ii fgetty 0.7-11
-- no debconf information
--
I'd like to live like a poor person with lots of money.
Acknowledgement sent
to Andrew Bower <[email protected]>:
Extra info received and forwarded to list. Copy sent to Lorenzo Puliti <[email protected]>.
(Mon, 14 Apr 2025 16:48:02 GMT) (full text, mbox, link).
Subject: Re: Bug#1103152: Starts 2nd getty on hvc0, making console login
(almost) impossible
Date: Mon, 14 Apr 2025 17:45:48 +0100
Hi Andras and Lorenzo,
On Mon, Apr 14, 2025 at 04:28:36PM +0200, Andras Korn wrote:
> During a dist-upgrade, the getty-run package was pulled in, and a(n
> IMO misleadingly named) getty-ttyS0 service enabled by default.
IMO the system should not start anything on a serial port without user
configuration and systemd is wrong to do this by default: anything could
be connected and we have no idea in which order such devices will be
enumerated. The default inittab gets this right by showing how to do it
but not enabling it.
A simple remedy to this issue would therefore be to configure this
service 'down' by default until enabled by the user.
However, it does seem a bit harsh to rate this as critical as this
service was also enabled by default in bookworm and the system does need
to have been configured by the user already for the reported scenario to
occur, in which case the superfluous service could have been disabled.
Andrew
Acknowledgement sent
to Andrew Bower <[email protected]>:
Extra info received and forwarded to list. Copy sent to Lorenzo Puliti <[email protected]>.
(Mon, 14 Apr 2025 19:39:03 GMT) (full text, mbox, link).
Subject: Re: Bug#1103152: Starts 2nd getty on hvc0, making console login
(almost) impossible
Date: Mon, 14 Apr 2025 20:37:05 +0100
On Mon, Apr 14, 2025 at 09:32:55PM +0200, Andras Korn wrote:
> On Mon, Apr 14, 2025 at 05:45:48PM +0100, Andrew Bower wrote:
>
> > On Mon, Apr 14, 2025 at 04:28:36PM +0200, Andras Korn wrote:
> > > During a dist-upgrade, the getty-run package was pulled in, and a(n
> > > IMO misleadingly named) getty-ttyS0 service enabled by default.
> >
> > IMO the system should not start anything on a serial port without user
> > configuration
>
> (Incidentally, I agree, but this bugreport is about something else.)
>
> > A simple remedy to this issue would therefore be to configure this
> > service 'down' by default until enabled by the user.
>
> Or just install it but don't symlink it into /etc/services.
Yes, I think that would be the preferred way - saves a running runsv
instance.
> (I submit that it's easier to fix a system that you can't log into because you realize after a reboot that there is no getty than a system you don't want to reboot just now that you can't get into because there are two concurrent gettys.)
>
> > However, it does seem a bit harsh to rate this as critical as this
> > service was also enabled by default in bookworm and the system does need
> > to have been configured by the user already for the reported scenario to
> > occur, in which case the superfluous service could have been disabled.
>
> My justification for "critical" is that this runit service was enabled automatically and that it "broke the system" (fsvo).
>
> With that said, if you think it should be downgraded, I won't object further.
I'm just another user commenting, not the maintainer - I'll leave it to
him to triage! But it's a sensitive time for raising critical bugs with
the trixie freeze as we don't want runit cut out of the release! :-)
> Re bookworm: this particular system uses sid and was upgraded frequently. The console login functionality wasn't tested frequently; for all I know it could've been broken for years.
I see.
Acknowledgement sent
to Andras Korn <[email protected]>:
Extra info received and forwarded to list. Copy sent to Lorenzo Puliti <[email protected]>.
(Mon, 14 Apr 2025 19:42:03 GMT) (full text, mbox, link).
Subject: Re: Bug#1103152: Starts 2nd getty on hvc0, making console login
(almost) impossible
Date: Mon, 14 Apr 2025 21:32:55 +0200
On Mon, Apr 14, 2025 at 05:45:48PM +0100, Andrew Bower wrote:
> On Mon, Apr 14, 2025 at 04:28:36PM +0200, Andras Korn wrote:
> > During a dist-upgrade, the getty-run package was pulled in, and a(n
> > IMO misleadingly named) getty-ttyS0 service enabled by default.
>
> IMO the system should not start anything on a serial port without user
> configuration
(Incidentally, I agree, but this bugreport is about something else.)
> A simple remedy to this issue would therefore be to configure this
> service 'down' by default until enabled by the user.
Or just install it but don't symlink it into /etc/services.
(I submit that it's easier to fix a system that you can't log into because you realize after a reboot that there is no getty than a system you don't want to reboot just now that you can't get into because there are two concurrent gettys.)
> However, it does seem a bit harsh to rate this as critical as this
> service was also enabled by default in bookworm and the system does need
> to have been configured by the user already for the reported scenario to
> occur, in which case the superfluous service could have been disabled.
My justification for "critical" is that this runit service was enabled automatically and that it "broke the system" (fsvo).
With that said, if you think it should be downgraded, I won't object further.
Re bookworm: this particular system uses sid and was upgraded frequently. The console login functionality wasn't tested frequently; for all I know it could've been broken for years.
András
--
Dr. Frankenstein entered a body building contest.
Upon arrival he realised he had misunderstood the objective.
Subject: Re: Bug#1103152: Starts 2nd getty on hvc0, making console login
(almost) impossible
Date: Wed, 16 Apr 2025 00:50:13 +0200
Control: tags -1 moreinfo
Hi Andras,
Hi Andrew,
On Mon, 14 Apr 2025 16:28:36 +0200
Andras Korn <[email protected]> wrote:
> Package: getty-run
> Version: 2.2.0-2
> Severity: critical
> Justification: makes console logins all but impossible, thus arguably
> breaking the entire system
>
> Hi,
>
> I have a VPS that's a domU guest, so its console is /dev/hvc0.
>
> I had my own getty service on it, called getty-hvc0.
>
> During a dist-upgrade, the getty-run package was pulled in, and a(n
> IMO misleadingly named) getty-ttyS0 service enabled by default.
>
> This system doesn't have a /dev/ttyS0, but that doesn't stop the
> getty-ttyS0 service from doing this:
>
> --- 8< ---
[snip]
> fi
> + pgrep -x agetty -t hvc0
> + pgrep -x fgetty -t hvc0
>
[snip]
>
> Since I already had a getty on hvc0, the two gettys ended up fighting
> over the console input, making it *very tricky* to log in
> successfully.
>
> If you think you must go and enable services unconditionally by
> default, please somehow make sure this doesn't happen; for example,
> add something like this:
>
> if fuser -v "$SGETTY" 2>&1 | grep -q getty; then exec sleep 3600; fi
So, something like this already happened (#895904) and I thought we
already have a test in the run script,
pgrep -x agetty -t "$SGETTY"
pgrep -x fgetty -t "$SGETTY"
but the test is incomplete in that it only catches a getty waiting for
login, but not one with a shell already connected, as in your use case.
(this is also true for gettys on /dev/tty[1-6])
another problem is that neither pgrep (procps package) nor fuser nor
lsof are essential so getty-run is missing a dependency (since 2018)...
About the test I was wondering if a plain
pgrep -t "$SGETTY"
would be correct (disregarding the name of the process).
If there is a process on the getty can I assume the getty is busy?
Any case of false positive you can think of?
(on my system seems to work reliably, not sure about containers)
Andrew, Andras, any opinion on the above simplified test?
About the missing dependency, I'm not eager to add one, so I was
thinking of a recommend and make the test conditional to
[ -e /usr/bin/pgrep ]
For the record, I'm also available to discuss whether is a good idea to
enable this specific service by default, I don't have a strong opinion
on that, but is a subject for a separate bug and I'm not going to
change that during the release process (so it can happen after Trixie)
Lorenzo
>
> (Not perfect, but it would have helped me at least.)
>
> (Also, unrelated, but not worth its own bugreport:
>
> 1. if /dev/$SGETTY is not found, you stop the service; but maybe the
> getty will appear later, for example when a module is loaded, or a
> device is (re)connected to the system.
>
> 2. you hardwired the name of the service into the script. I think it
> would be better to do "exec sv d ." to stop the service, whatever it
> may be called, as the last action, similar how you'd use "exit" in a
> plain shell script.)
P.S.
will fix point 2. too.
>
> András
>
Acknowledgement sent
to Andras Korn <[email protected]>:
Extra info received and forwarded to list. Copy sent to Lorenzo Puliti <[email protected]>.
(Wed, 16 Apr 2025 14:30:01 GMT) (full text, mbox, link).
Subject: Re: Bug#1103152: Starts 2nd getty on hvc0, making console login
(almost) impossible
Date: Wed, 16 Apr 2025 16:26:00 +0200
On Wed, Apr 16, 2025 at 12:50:13AM +0200, Lorenzo wrote:
> > This system doesn't have a /dev/ttyS0, but that doesn't stop the
> > getty-ttyS0 service from doing this:
> >
> > --- 8< ---
>
> [snip]
>
> > fi
> > + pgrep -x agetty -t hvc0
> > + pgrep -x fgetty -t hvc0
> >
> [snip]
Ah, right. It didn't catch my getty, because it's neither agetty nor fgetty but plain getty:
root 1979 0.0 0.0 2344 160 ? Ss 2023 0:21 \_ runsv getty-hvc0
root 18185 0.0 0.0 2660 944 ? S Apr14 0:00 | \_ /sbin/getty 38400 hvc0
And also because getty's controlling tty isn't /dev/hvc0; it uses (has an FD open for) that character device, but it's not its ctty:
# pgrep -x getty -t hvc0
[1] 32407 exit 1 pgrep -x getty -t hvc0
> > if fuser -v "$SGETTY" 2>&1 | grep -q getty; then exec sleep 3600; fi
>
> So, something like this already happened (#895904) and I thought we
> already have a test in the run script,
>
> pgrep -x agetty -t "$SGETTY"
> pgrep -x fgetty -t "$SGETTY"
Unfortunately, this test apparently just doesn't work. The getty process has no controlling tty:
# cat /proc/18185/stat
18185 (getty) S 1979 1979 1979 0 -1 4194560 159 0 0 0 0 1 0 0 20 0 1 0 6638251059 2723840 236 18446744073709551615 94739846283264 94739846346029 140721031136256 0 0 0 0 131078 0 1 0 0 17 0 0 0 0 0 0 94739846374864 94739846378704 94739860475904 140721031143277 140721031143300 140721031143300 140721031143404 0
(Field 7 is zero; it should contain the device number of the ctty.)
I suppose if I were to start getty from a terminal, it would have a ctty, but that would be the terminal it was started from, not the one it's managing.
> About the test I was wondering if a plain
>
> pgrep -t "$SGETTY"
>
> would be correct (disregarding the name of the process).
> If there is a process on the getty can I assume the getty is busy?
Apparently not; see above.
> About the missing dependency, I'm not eager to add one, so I was
> thinking of a recommend and make the test conditional to
> [ -e /usr/bin/pgrep ]
I don't think you should do this. `pgrep` could be anywhere on the PATH; if it doesn't exist, you won't be able to run it anyway, so testing for its existence in a particular directory doesn't improve anything, just causes pgrep not to be run if it's in an unexpected ___location.
That said, the pgrep test seems to be completely unreliable.
I still think the best would be not to install this service by default, because making it robust enough would make it too complex.
> > 1. if /dev/$SGETTY is not found, you stop the service; but maybe the
> > getty will appear later, for example when a module is loaded, or a
The tty, not the getty (sorry if this was confusing)
András
--
The world will end in 5 minutes. Please log out.
Subject: Re: Bug#1103152: Starts 2nd getty on hvc0, making console login
(almost) impossible
Date: Thu, 17 Apr 2025 00:26:00 +0200
Hi Andras,
On Wed, 16 Apr 2025 16:26:00 +0200 Andras Korn
<[email protected]> wrote:
> On Wed, Apr 16, 2025 at 12:50:13AM +0200, Lorenzo wrote:
>
> > > This system doesn't have a /dev/ttyS0, but that doesn't stop the
> > > getty-ttyS0 service from doing this:
> > >
> > > --- 8< ---
> >
> > [snip]
> >
> > > fi
> > > + pgrep -x agetty -t hvc0
> > > + pgrep -x fgetty -t hvc0
> > >
> > [snip]
>
> Ah, right. It didn't catch my getty, because it's neither agetty nor
> fgetty but plain getty:
>
> root 1979 0.0 0.0 2344 160 ? Ss 2023 0:21 \_
> runsv getty-hvc0 root 18185 0.0 0.0 2660 944 ? S
> Apr14 0:00 | \_ /sbin/getty 38400 hvc0
>
> And also because getty's controlling tty isn't /dev/hvc0; it uses
> (has an FD open for) that character device, but it's not its ctty:
does your test with fuser work?
something like
'fuser /dev/hvc0'
I don't have a VPS with hvc0 (Xen?) but I did some testing:
pgrep seems to work for physical hardware systems but it fails in
qemu and in docker (but only if unprivileged), while fuser seems to work
in all cases that I was able to test..
> I still think the best would be not to install this service by
> default, because making it robust enough would make it too complex.
ok but, for several reasons, after Trixie release. Meanwhile it's better
to fix this in some way, even if not perfect. Otherwise I'll have to
downgrade the severity and put it on hold.
Let me know,
Lorenzo
Acknowledgement sent
to Andras Korn <[email protected]>:
Extra info received and forwarded to list. Copy sent to Lorenzo Puliti <[email protected]>.
(Tue, 22 Apr 2025 08:15:02 GMT) (full text, mbox, link).
Subject: Re: Bug#1103152: Starts 2nd getty on hvc0, making console login
(almost) impossible
Date: Tue, 22 Apr 2025 10:13:43 +0200
On Fri, Apr 18, 2025 at 11:35:49AM +0200, Lorenzo wrote:
Hi,
> updated patch with fuser attached
I think it looks good; I'd still consider just sleeping if the /dev node isn't there (because maybe it'll be there later), but I think the patch should adequately address the problem of starting several gettys on the same console.
András
--
All that glisters may not be gold, but at least it contains free electrons.
Subject: Re: Bug#1103152: Starts 2nd getty on hvc0, making console login
(almost) impossible
Date: Sat, 26 Apr 2025 19:21:04 +0200
Control: tags -1 -moreinfo
On Tue, 22 Apr 2025 10:13:43 +0200 Andras Korn
<[email protected]> wrote:
> On Fri, Apr 18, 2025 at 11:35:49AM +0200, Lorenzo wrote:
>
> Hi,
>
> > updated patch with fuser attached
>
> I think it looks good; I'd still consider just sleeping if the /dev
> node isn't there (because maybe it'll be there later), but I think
> the patch should adequately address the problem of starting several
> gettys on the same console.
Thanks,
Lorenzo
>
> András
>
> --
> All that glisters may not be gold, but at least it contains free
> electrons.
>
>
Control: tag -1 pending
Hello,
Bug #1103152 in runit reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/debian/runit/-/commit/6142d7b9f1ab17a680ebef0c306c12139aeb9376
------------------------------------------------------------------------
getty-run: fix tests for busy getty device
* fix tests for when a getty is already busy with a process, use
fuser that seem to work better in certain container environment
* use 'exec sv d .' to stop the service, more robust to service
name changes
* recommends: psmisc. It's not necessary to guard pgrep calls: due
the fact that pgrep returns 0 on success, the test logic continue
with the runscript if the pgrep call returns nonzero.
Closes: #1103152
------------------------------------------------------------------------
(this message was generated automatically)
--
Greetings
https://bugs.debian.org/1103152
Source: runit
Source-Version: 2.2.0-3
Done: Lorenzo Puliti <[email protected]>
We believe that the bug you reported is fixed in the latest version of
runit, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to [email protected],
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Lorenzo Puliti <[email protected]> (supplier of updated runit package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing [email protected])
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Format: 1.8
Date: Sat, 26 Apr 2025 22:25:25 +0200
Source: runit
Architecture: source
Version: 2.2.0-3
Distribution: unstable
Urgency: medium
Maintainer: Lorenzo Puliti <[email protected]>
Changed-By: Lorenzo Puliti <[email protected]>
Closes: 1103152
Changes:
runit (2.2.0-3) unstable; urgency=medium
.
* getty-run: fix tests for busy getty device (Closes: #1103152)
* try to improve NEWS for bookworm to trixie upgrade
* d/copyright: update FSF address
Checksums-Sha1:
56b2548dd799e66488e43d6ad5ac3fe63d3b7fc5 2053 runit_2.2.0-3.dsc
297f180f59eff10b5b9e604692c11fdc35e7099f 70008 runit_2.2.0-3.debian.tar.xz
e2d5d9fdc12bb243a280dcee100e5ed04d9c23a3 5572 runit_2.2.0-3_source.buildinfo
Checksums-Sha256:
10caac92fd7ce53231d3113f816ea2cacca03c4ba3de98729d47cf4bc6961c68 2053 runit_2.2.0-3.dsc
a370d97ade1e0d98eff99ad809a4486599e0512262b6d3d8385c73f35598cac0 70008 runit_2.2.0-3.debian.tar.xz
22bf44af6070b20868ce00a23adb6f7cefaeef9fb234917c5c8ee6235901c901 5572 runit_2.2.0-3_source.buildinfo
Files:
10e8d5db0cde480d3e2f8547e2d9d117 2053 admin optional runit_2.2.0-3.dsc
a1d6f9d125984eb479bc5b5c8670d1dd 70008 admin optional runit_2.2.0-3.debian.tar.xz
d9928b3b5dbc44b839e6cd99d477fec6 5572 admin optional runit_2.2.0-3_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQHEBAEBCgAuFiEEQGIgyLhVKAI3jM5BH1x6i0VWQxQFAmgR0P8QHGJhZ2VAZGVi
aWFuLm9yZwAKCRAfXHqLRVZDFKzEC/9O6kDBjZdB7XU0KBx3MafJ8B/VbHaSO7Ou
I90QqTwT1qnhD4jjEK0+MMr725Z+Trjbr/YzRWyHioz+TPhrWGns5oecJ/37i7ZO
hMtHsw0wB0SlQpiHf31dZwCVP1XqwdqfLpXYYFlLWeBxNoek0oeWcmEHc2BVzCqJ
/TtINBEZrztqxIbioe4ZmDbrrFjnYZP/qC+H24oFQkNeaANUJj7rbWiqcPeDB1bq
QKJ05MZ3W0C23FI3uOgGjvM/j0ZrckLquq9vzG3k35DdggrbZOtkeok0bNnsEP2V
Qg43ufi1Ugy7Ms57syEVTqhSckMOYnORXGtuJmH8z/6DC5Z0Eznlev62zsFvvXjw
GPFP6VCikS6WhamX4IblkgYrWmCMsUXWe0Utip22Syo4phUYKguUmxFuarXrk2kR
MFqIT/M+FTLmt2PF4QJECcHu3Hxenm8ylWGPFKQKHpdybDn7Nfq3/L2cMoVzLbyN
0KNRId8ECqml7mkaphU3b77mCI9Ud2c=
=ETo/
-----END PGP SIGNATURE-----
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.