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