Package: getty-run Version: 2.1.2-11 Severity: important
-- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.12-van (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) ( EDIT: It's actually runit ) Versions of packages getty-run depends on: ii runit 2.1.2-11 ii runit-helper 2.7.2 Versions of packages getty-run recommends: ii fgetty 0.7-3 getty-run suggests no packages. -- Configuration Files: /etc/sv/getty-tty3/finish changed: SERVICE=getty-tty3 [ $1 = 163 ] && echo "runsv: ERROR $1 in $SERVICE: another getty already on tty3" \ && sv d $(dirname $0) && exit 0 exec utmpset -w tty3 /etc/sv/getty-tty3/run changed: pgrep -x getty -t tty3 && exit 163 pgrep -x agetty -t tty3 && exit 163 ! type fgetty >/dev/null 2>&1 || exec chpst -P fgetty tty3 exec getty 38400 tty3 linux -- no debconf information Welcome back :) The getty-run package does not check whether the tty is busy with another getty (nor try to stop the already-running getty) before starting the getty-ttyX services. As far as I know the default is to have a getty running in each of the six ttys, so the conflict will happen by default unless the admin takes some action to prevent it. In my case the getty-run package was installed as a dependency of runit-init, so I start noticing the cpu usage at 100% and it took me a while to understand why.. A easy way to prevent this is to check for an already runing getty (and exit if such a getty is found) in the run file as you see in the /etc/sv/getty-tty3/run file attached above; also, it's good to print some debug message that explain why the service is not running and finally do a 'sv d service', otherwise runit will endlessly try to restart the service ( see the finish file above). Many Thanks Lorenzo
