Control: tags -1 moreinfo Hi Andras, Hi Andrew,
On Mon, 14 Apr 2025 16:28:36 +0200 Andras Korn <korn-debb...@elan.rulez.org> wrote: > Package: getty-run > Version: 2.2.0-2 > Severity: critical > Justification: makes console logins all but impossible, thus arguably > breaking the entire system > > Hi, > > I have a VPS that's a domU guest, so its console is /dev/hvc0. > > I had my own getty service on it, called getty-hvc0. > > During a dist-upgrade, the getty-run package was pulled in, and a(n > IMO misleadingly named) getty-ttyS0 service enabled by default. > > 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] > > Since I already had a getty on hvc0, the two gettys ended up fighting > over the console input, making it *very tricky* to log in > successfully. > > If you think you must go and enable services unconditionally by > default, please somehow make sure this doesn't happen; for example, > add something like this: > > 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" but the test is incomplete in that it only catches a getty waiting for login, but not one with a shell already connected, as in your use case. (this is also true for gettys on /dev/tty[1-6]) another problem is that neither pgrep (procps package) nor fuser nor lsof are essential so getty-run is missing a dependency (since 2018)... 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? Any case of false positive you can think of? (on my system seems to work reliably, not sure about containers) Andrew, Andras, any opinion on the above simplified test? 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 ] For the record, I'm also available to discuss whether is a good idea to enable this specific service by default, I don't have a strong opinion on that, but is a subject for a separate bug and I'm not going to change that during the release process (so it can happen after Trixie) Lorenzo > > (Not perfect, but it would have helped me at least.) > > (Also, unrelated, but not worth its own bugreport: > > 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 > device is (re)connected to the system. > > 2. you hardwired the name of the service into the script. I think it > would be better to do "exec sv d ." to stop the service, whatever it > may be called, as the last action, similar how you'd use "exit" in a > plain shell script.) P.S. will fix point 2. too. > > András >
