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.
