On Mon, Mar 23, 2026 at 23:35:09 +0000, Andy Smith wrote: > I don't fully understand the situation, but if it is that: > > 1. All your processes receive a SIGTERM > 2. Your editor writes a message about that to your terminal > 3. Your terminal already exited because it got a SIGTERM > 3. So your editor never manages to write its message and then doesn't > follow through with writing open buffers to recovery file > > …then I would say that the bug is in the editor because writes to file > descriptors aren't guaranteed to succeed or even to not block forever, > so should it really be blocking an emergency action on the success of > that? > > If we were to argue that the bug is in systemd, what would be the > systemd fix to that situation?
If I recall correctly, it was reported that the issue also occurs if the editor is running on a Linux virtual console (/dev/tty2 or whatever). In that case, unless I'm *very* confused, I don't believe there is any process associated with the terminal, or at least no process that can be terminated by a signal. In that specific scenario, I wonder whether the virtual consoles are being de-allocated prematurely. If they are, then that *could* be something within systemd that could be re-ordered. If not, then what's causing the error messages to fail/block? At that point, I would want to see an strace of the editor being signalled, and see exactly what happens. This could be incredibly tricky to arrange, though. The trace log would need to continue being written while the system is being torn down. I don't know whether that's possible.
