On Mon, Mar 23, 2026 at 11:35:09PM +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?
Yes: it tries to write to the TTY, it does not test if this succeeds, but it fails in a way that stops it from proceeding: either by blocking (forever) or by killing it. > If we were to argue that the bug is in systemd, what would be the > systemd fix to that situation? Prolly a change in order of shutting things down so that ttys continue to work until user processes have terminated. This is analogous to keeping file systems writable until user processes have terminated. (This fails on console ttys as well as gnome terminals.) I have now fixed the editor to not send anything to the terminal if SIGTERM is received. > But perhaps I have misunderstood. No, you got it right. As seen with my link to IBM - I am not the only one that this would have tripped up. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 https://www.phcomp.co.uk/ Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html #include <std_disclaimer.h>
