On Wed, Apr 16, 2025 at 12:50:13AM +0200, Lorenzo wrote:
> > This system doesn't have a /dev/ttyS0, but that doesn't stop the
> > getty-ttyS0 service from doing this:
> >
> > --- 8< ---
>
> [snip]
>
> > fi
> > + pgrep -x agetty -t hvc0
> > + pgrep -x fgetty -t hvc0
> >
> [snip]
Ah, right. It didn't catch my getty, because it's neither agetty nor fgetty but
plain getty:
root 1979 0.0 0.0 2344 160 ? Ss 2023 0:21 \_ runsv
getty-hvc0
root 18185 0.0 0.0 2660 944 ? S Apr14 0:00 | \_
/sbin/getty 38400 hvc0
And also because getty's controlling tty isn't /dev/hvc0; it uses (has an FD
open for) that character device, but it's not its ctty:
# pgrep -x getty -t hvc0
[1] 32407 exit 1 pgrep -x getty -t hvc0
> > if fuser -v "$SGETTY" 2>&1 | grep -q getty; then exec sleep 3600; fi
>
> So, something like this already happened (#895904) and I thought we
> already have a test in the run script,
>
> pgrep -x agetty -t "$SGETTY"
> pgrep -x fgetty -t "$SGETTY"
Unfortunately, this test apparently just doesn't work. The getty process has no
controlling tty:
# cat /proc/18185/stat
18185 (getty) S 1979 1979 1979 0 -1 4194560 159 0 0 0 0 1 0 0 20 0 1 0
6638251059 2723840 236 18446744073709551615 94739846283264 94739846346029
140721031136256 0 0 0 0 131078 0 1 0 0 17 0 0 0 0 0 0 94739846374864
94739846378704 94739860475904 140721031143277 140721031143300 140721031143300
140721031143404 0
(Field 7 is zero; it should contain the device number of the ctty.)
I suppose if I were to start getty from a terminal, it would have a ctty, but
that would be the terminal it was started from, not the one it's managing.
> About the test I was wondering if a plain
>
> pgrep -t "$SGETTY"
>
> would be correct (disregarding the name of the process).
> If there is a process on the getty can I assume the getty is busy?
Apparently not; see above.
> About the missing dependency, I'm not eager to add one, so I was
> thinking of a recommend and make the test conditional to
> [ -e /usr/bin/pgrep ]
I don't think you should do this. `pgrep` could be anywhere on the PATH; if it
doesn't exist, you won't be able to run it anyway, so testing for its existence
in a particular directory doesn't improve anything, just causes pgrep not to be
run if it's in an unexpected location.
That said, the pgrep test seems to be completely unreliable.
I still think the best would be not to install this service by default, because
making it robust enough would make it too complex.
> > 1. if /dev/$SGETTY is not found, you stop the service; but maybe the
> > getty will appear later, for example when a module is loaded, or a
The tty, not the getty (sorry if this was confusing)
András
--
The world will end in 5 minutes. Please log out.
