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

Processing control commands:

tags -1 moreinfo

Bug #1103152 [getty-run] Starts 2nd getty on hvc0, making console login (almost) impossible
Ignoring request to alter tags of bug #1103152 to the same tags previously set

--
1103152: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103152
Debian Bug Tracking System
Contact [email protected] with problems

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Control: tags -1 patch

Hi,
patch attached

Andrew, Andras,
let me know if this looks good to you

Best,
Lorenzo


From 58a61460b572460e67dc911a9eea60bd9b8c6529 Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti <[email protected]>
Date: Wed, 16 Apr 2025 10:50:18 +0200
Subject: [PATCH] getty-run: fix tests for busy getty device

* fix tests for when a getty is already busy with a process
* use 'exec sv d .' to stop the service, more robust to service
name changes
* recommends: procps. 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
---
debian/control | 3 ++-
debian/sv/getty-hvc0/finish | 7 +++----
debian/sv/getty-hvc0/run | 4 ++--
debian/sv/getty-ttyS0/run | 22 +++++++++++-----------
debian/sv/getty.in/finish.in | 7 +++----
debian/sv/getty.in/run.in | 4 ++--
6 files changed, 23 insertions(+), 24 deletions(-)

diff --git a/debian/control b/debian/control
index c5c3fa0..26adb01 100644
--- a/debian/control
+++ b/debian/control
@@ -55,9 +55,10 @@ Description: service supervision (systemd and sysv integration)

Package: getty-run
Architecture: all
-Suggests: fgetty
Breaks: ${runit:Breaks}
Depends: ${misc:Depends}, ${shlibs:Depends}
+Recommends: procps
+Suggests: fgetty
Description: runscripts to supervise getty processes
runit is a collection of tools to provide system-wide service supervision
and to manage services. Contrary to sysv init, it not only cares about
diff --git a/debian/sv/getty-hvc0/finish b/debian/sv/getty-hvc0/finish
index 5f43afb..2be1242 100755
--- a/

Processing control commands:

tags -1 patch

Bug #1103152 [getty-run] Starts 2nd getty on hvc0, making console login (almost) impossible
Added tag(s) patch.

--
1103152: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103152
Debian Bug Tracking System
Contact [email protected] with problems

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Processing control commands:

tags -1 -moreinfo

Bug #1103152 [getty-run] Starts 2nd getty on hvc0, making console login (almost) impossible
Removed tag(s) moreinfo.

--
1103152: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103152
Debian Bug Tracking System
Contact [email protected] with problems

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Processing control commands:

tag -1 pending

Bug #1103152 [getty-run] Starts 2nd getty on hvc0, making console login (almost) impossible
Added tag(s) pending.

--
1103152: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103152
Debian Bug Tracking System
Contact [email protected] with problems

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format...

Your message dated Wed, 30 Apr 2025 07:54:46 +0000
with message-id <[email protected]>
and subject line Bug#1103152: fixed in runit 2.2.0-3
has caused the Debian Bug report #1103152,
regarding Starts 2nd getty on hvc0, making console login (almost) impossible
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected]
immediately.)


--
1103152: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103152
Debian Bug Tracking System
Contact [email protected] with problems

Received: (at submit) by bugs.debian.org; 14 Apr 2025 14:35:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.6-bugs.debian.org_2005_01_02
(2021-04-09) on buxtehude.debian.org
X-Spam-Level:
X-Spam-Status: No, score=-15.0 required=4.0 tests=BAYES_00,
BODY_INCLUDES_PACKAGE,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FOURLA,
HAS_PACKAGE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no
version=3.4.6-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 25; hammy, 150; neutral, 218; spammy,
0. spammytokens: hammytokens:0.000-+--trixie, 0.000-+--sk:taint_o,
0.000-+--sk:TAINT_O, 0.000-+--sk:taint_u, 0.000-+--sk:TAINT_U Return-path: <korn-submit=[email protected]>
Received: from elan.rulez.org ([81.0.124.36]:47064 helo=arcadia.elan.rulez.org)
by buxtehude.debian.org with esmtp (Exim 4.94.2)
(envelope-from <korn-submit=bugs.d