Dear Maintainer, After upgrading from 2.2.0-2 to 2.2.0-3, I noticed $ ps -HAf | grep [r]unsvdir root 1738 1 0 10:24 ? 00:00:00 runsvdir -P /etc/service log: run: 21: fuser: not found /etc/sv/getty-ttyS0/run: 21: fuser: not found /etc/sv/getty-ttyS0/run: 21: fuser: not found /etc/sv/getty-ttyS0/run: 21: fuser: not found /etc/sv/getty-ttyS0/run: 21: fuser: not found /etc/sv/getty-ttyS0/run: 21: fuser: not found ./etc/sv/getty-ttyS0/run: 21: fuser: not found /etc/sv/getty-ttyS0/run: 21: fuser: not found /etc/sv/getty-ttyS0/run: 21: fuser: not found This comes about because I do not install recommended packages, meaning I had to manually install psmisc to fix this. Seeing that the /etc/sv/getty-*/run script now use fuser, I think the dependency on psmisc should be bumped from a Recommends: to a Depends:.
Hello Olaf,
sorry for very late reply:
Mmm, I agree that the spamming is annoying, but the error is not fatal
to the service, because the code is
if fuser -v /dev/"$SGETTY" ; then
echo "already another process on $SGETTY: stopping getty-ttyS0"
exec sv d .
fi
so if fuser is not found you get the error but the service goes ahead.
What I see is that the getty-ttyS0 is likely in a stop-restart loop, so
that need to be fixed.
There's probably a bug in the getty-ttyS0 script somewhere, but I need
more info to fix the real cause of this:
* do you have /dev/tty-S0 in you machine?
* Also the run file does some greppin on /proc/cmdline to guess the
"right" serial console and that might be wrong as well: could you
print the value of $SGETTY variable in the runscript, just before
the exec line and see if that is something weird/wrong?
recommends is appropriate.
More in general, you are installing without recommends because there is
some other package that recommends packages that are not useful to you;
what if that other package bumps his Recommends to Depends?
Now you don't consider psmisc a waste of space but other may want to
have a minimal installation without it, so if I bump it to Depends I
prevent other people to do that.
I see that you won't be happy with this call but I hope you can
understand the reasoning.
Best Regards,
Lorenzo
ping Olaf, I'm still interested and available to understand and fix the issue that causes the restart loop of the getty service, but I need you to provide more info to understand what causes the problem even better, if this comes (or is reproducible) from inside a container, you can provide me the commands to reproduce the issue myself. It's fine if it's a downstream that uses the debian package as is. Without further info I intend to close this bug on timeout in a couple of weeks or so. Best, Lorenzo
Hi Lorenzo,
Lorenzo <plorenzo@disroot.org> writes:
psmisc a Recommends:, all the /etc/sv/getty-*/run scripts, except the
one for ttyv0, call fuser *unconditionally* (if the device exists) and
exit with status 163 on failure. In that case (f)getty is not run.
Curiously, only /etc/sv/getty-ttyS0/run produces the "21: fuser: not
found" error message. Might that be caused by the different shebang for
that script?
I'm no expert but unconditionally calling fuser looks like it warrants a
Depends: to me. Unless something else handles the case where no ports
are opened for local login by the getty-run scripts.
# Guessing /etc/inittab could be responsible for that.
FWIW, psmisc Depends: on libc6 and libtinfo6, as does bash, and has no
Recommends:, at least on amd64, so there would be no additional
dependencies that need installing.
# Actually, bash Pre-Depends: on those packages.
No, but I have /dev/ttyS0 thru /dev/ttyS3.
BTW, the error message is about the fuser command on line 21 not being
found.
My /proc/cmdline has no 'console=' in it and
/etc/sv/getty-ttyS0/env/SGETTY is empty so SGETTY would become ttyS0,
IIUC.
Whatever its value, the exec in
if ! test -c /dev/"$SGETTY" ; then
echo "/dev/$SGETTY not found: stopping getty-ttyS0"
exec sv d .
fi
does not trigger because the script attempts to run fuser right after
the above conditional, as per the error message.
The issue occurs on physical hardware and I currently run with psmisc
installed. Removing it would pull syncthing-gtk with it ...
I am not sure how I would go about reproducing this in a container,
maybe better to try in a minimal VM with all the tty devices there.
I don't fancy volume mounting my machine's /dev/ in a container ;-)
Hope this helps,
Hi Olaf,
thanks for the follow-up:
On Wed, 02 Sep 2026 12:55:42 +0900 Olaf Meeuwissen <paddy-hack@member.fsf.org> wrote:
I've changed runscripts so that now they check for fuser before calling
it; the bottom line is that, since the test is only useful when runit
is not init (especially when switching init from systemd or sysvinit)
and the primary use case for getty-run is runit as init, I prefer not to
add the dependency.
For comparison, getties on other init systems do not test for busy
devices at all.
Yes, most systems will have psmisc already installed, but Debian folks
responsible for the essential set decided that psmisc was not
essential, and there are use case like minimal chroot for testing or
container where a small footprint in term of dependencies matters.
Since runit (as init) does not need psmisc to function I prefer to not
add the extra Dependency and keep runit dependencies minimal (for the
record, I'm working on removing the runit-helper dependency and to
reduce the footprint of the sysuser-helper one)
after invoke-run execs the run script, it's just as a standard shell
note that the current code for /etc/sv/getty-ttyS0/run is
if fuser -v /dev/"$SGETTY" ; then
echo "already another process on $SGETTY: stopping getty-ttyS0"
exec sv d .
fi
so I don't think fuser missing is the cause for your getty restart
loop, for example
cat ./test.sh
-----------------------
#!/bin/bash
#set -e
if bleah /dev/"$SGETTY" ; then
echo "getty stopped"
fi
echo "reached even if bleah is not found"
exit
------------------------------------
$ ./test
./test: line 4: bleah: command not found
reached even if bleah is not found
if your getty keeps restarting after you upgrade to 2.1.3-5 feel free
to open another bug and attach your /etc/sv/getty-ttyS0 script.
Best Regards,
Lorenzo
typo, I mean 2.3.1-5
Hello, Bug #1105907 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/54bf2eb1624752f260811a56df6de61d4e872eda ------------------------------------------------------------------------ getty-run: always test for fuser before calling it always check if fuser is executable in the system before calling it to detect if the getty device is already in use. we don't want to change the Recommends to Depends because the test is only useful when runit is not init (especially when switching frok systemd or sysvinit) but it's not actually used when runit is init. Closes: #1105907 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1105907
Hello, Bug #1105907 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/54bf2eb1624752f260811a56df6de61d4e872eda ------------------------------------------------------------------------ getty-run: always test for fuser before calling it always check if fuser is executable in the system before calling it to detect if the getty device is already in use. we don't want to change the Recommends to Depends because the test is only useful when runit is not init (especially when switching frok systemd or sysvinit) but it's not actually used when runit is init. Closes: #1105907 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1105907
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 1105907@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Lorenzo Puliti <plorenzo@disroot.org> (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 ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 02 Oct 2026 16:19:22 +0200
Source: runit
Architecture: source
Version: 2.3.1-5
Distribution: unstable
Urgency: medium
Maintainer: Lorenzo Puliti <plorenzo@disroot.org>
Changed-By: Lorenzo Puliti <plorenzo@disroot.org>
Closes: 923449 1105907 1143778 1144866
Changes:
runit (2.3.1-5) unstable; urgency=medium
.
* default-syslog: silence socklog-check output
* add runsv-cg for setting up cgroups on runit
* stage 1: setup (mount) cgroup2
* add a manpage for runsv-cg
* runsv-cg:
- fix typo
- do not require runit as init
* use /sys/fs/cgroup/runit for runit's services cgroups
* invoke-run, finish-exec: add optional cgroup support (Closes: #923449)
* invoke-run:
- update manpage for cgroups
- allow users to control verbosity for user services (Closes: #1143778)
- clarify home directory for user services in manpage
* runit-run: fix race at systemd shutdown.
+ thanks to Jan Braun <janbraun@gmx.de> (Closes: #1144866)
* getty-run: always test for fuser before calling it (Closes: #1105907)
* d/control: use dh-sequence for dh_runit and dh_sysuser
* d/control: drop {runit:Breaks} and {runit:Conflicts} for runit
* d/control (runit-run): drop ancient Breaks and Replaces
* bump S-V to 4.7.4, no changes required
Checksums-Sha1:
8b86709175d2df04fa1cccd7452c10b8a6d24deb 2265 runit_2.3.1-5.dsc
4d5550a17d5ffb8d9270bb139549e2a7125a2a41 90448 runit_2.3.1-5.debian.tar.xz
bc4b5c13462a9f9fcd420ac476b071a85cee09c9 6934 runit_2.3.1-5_amd64.buildinfo
Checksums-Sha256:
538a06cba27ef5f51e6e48b49d5bfaf98789a2ee635fda439d4bc53e590230f0 2265 runit_2.3.1-5.dsc
4a13705a96dd79d19555584242ba51420b1e871da76ae07dd25845f2a5ed1a21 90448 runit_2.3.1-5.debian.tar.xz
4ee723a42e71c06cbfe1953006b92280cb0ed43b8c499e376c20b0306a7a43ac 6934 runit_2.3.1-5_amd64.buildinfo
Files:
f33ea6456a4991f34f5d4a7dd1cc03ef 2265 admin optional runit_2.3.1-5.dsc
4a1892bbd1e1c971bcc40c39cab9baf3 90448 admin optional runit_2.3.1-5.debian.tar.xz
99e305bf0d8d87105b3ed75831c6ef6b 6934 admin optional runit_2.3.1-5_amd64.buildinfo
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE2ji91PGnrxOd1bVNxxYb07RU7gMFAmrBSAYACgkQxxYb07RU
7gNgaQ//V9hWXyGgsIvtwkn6jdgFmptQJxKNtJMsGSPJLGLDWg5uUfYqtycc5FQi
JwsG4xNckWwnqQB0RiBIVDL3YlxWYf0paZYIjNLoquBtFJZt0WrpYqgmSYJM+Hnj
Tv7rle73pS8i6KzGtu0zkC02M6U/06oCYHEcqRiKlbxlnVfUpqKUb4rAzYQj+BW5
OZSZONKNPBt1EKKY3YCUYCltLvpss6CnGod8lOQZ1nqi52Tugupi+9Rk7UvM5hOy
i+zQA3GbfDyaFO5tE4vRc0dWyQsFhtKim5tXBGPmrhU8KecUuXGr4DClVbOSddqC
lrwm8LzFUdkzzd/tCpDcGUcaQIpiFbx+ojcd24oDBc9G+evgzmgW1r6fjOT57ZXu
zqRSGptKaUQrJijI9ZzerpUtT2xvK9HP/diC14RQhguvZZk5K7pe4lNKgS6rYChu
q7k7xsURuzz4/SavuX3N+zTfRiWWU8g0e/aahQHCIiUkwDIH2IFDYkjxJUM/oy2R
McYp1iOV6SMss8ePikjrqZmkowvCipGqV7PzzwYB/KrQX7doHZY6EiV4fGnUzev5
Tme5wvuz5L/VvwhZ0FsyS4NUIPT0V5oEI0MfomyzdjpvsFZlRZO+NgZtCRez6HCw
aGvo2fYYOud0F56kWLmbuXnzRQfiZld3p2z60wq+mZF7s62zDdc=
=XwEp
-----END PGP SIGNATURE-----