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. 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. > 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? 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. > 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. 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 ;-) > Without further info I intend to close this bug on timeout in a couple > of weeks or so. > > Best, > Lorenzo Hope this helps, -- Olaf Meeuwissen
