Hi Olaf, thanks for the follow-up:
On Wed, 02 Sep 2026 12:55:42 +0900 Olaf Meeuwissen <[email protected]> wrote: > Hi Lorenzo, > > Lorenzo <[email protected]> writes: > > > ping > > Apologies for not following up on your earlier reaction. As for > keeping 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. > [...] > 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. 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. > 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. 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) > > 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? 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 > > 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. > > > On Sat, 17 May 2025 11:13:36 +0900 Olaf Meeuwissen > > <[email protected]> wrote: > >> 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 > > > > 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 > > > >> * do you have /dev/tty-S0 in you machine? > > No, but I have /dev/ttyS0 thru /dev/ttyS3. > > BTW, the error message is about the fuser command on line 21 not being > found. > > >> * 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? >
