The moment when you stay up until 3 AM to fix a problem. You give up and go to bed. And as you drift off to sleep you figure out the issue: running multiple programs that want to use the same interactive terminal concurrently is a bad idea and to fix it, you just close their standard input. Fixed it the next morning. Thank you brain! Context: I'm writing a testsuite checking all packages in Debian that ship anything in lib/tmpfiles.d with https://codeberg.org/Gardenhouse/seedfiles for GNU #Hurd support in #Debian

@werdahias is maintaining seedfiles in Debian and is pushing patches to experimental. There are 253 packages in Debian which ship files in tmpfiles.d and seedfiles only fails to create the same state compared to systemd-tmpfiles for 5 of those (the issue is the a+ type for setting POSIX ACLs). Unfortunately, the default timeout of 3h is too short for the salsa-ci runners to process these 253 packages in series, so I rewrote the shell script using Python asyncio spawning 2 processes in parallel.

@werdahias Oh I know that problem too! On MNT devices we need a getty on serial because display panel support is very brittle and when something goes wrong, serial is the only way to access the machine. That's when I learned how systemd sets up gettys using a generator and that systemd uses /proc/cmdline to decide what to start where. Related is the find that the order of console=ttyX args matters and if it's wrong, the LUKS passphrase prompt will only show up on serial and not on the screen. :D