Had a weird thing where my window manager's hotkey to start assword gui stopped doing anything. Apparently assword is trying to print out a warning (WARNING: could not validate OpenPGP signature on db file) and for some reason stderr is closed, so it crashes write(2, "print >>sys.stderr, \"WARNING: co"..., 80) = -1 EIO (Input/output error) close(4) = 0 munmap(0x7fea62219000, 4096) = 0 write(2, "IOError", 7) = -1 EIO (Input/output error) write(2, ": ", 2) = -1 EIO (Input/output error) write(2, "[Errno 5] Input/output error", 28) = -1 EIO (Input/output error) write(2, "\n", 1) = -1 EIO (Input/output error) I have no idea why my window manager is suddenly running the program with a closed or unwritable stderr, but probably crashing in this situation is not useful, so how about you catch this exception so that the gui can still display. Especially since the gui helpfully displays the same warning.. To reproduce: joey@darkstar:~>assword gui 2>/dev/full - exit 1
Hey, Joey. I'm trying to decide how reasonable it is for a program to expect that stderr be available, and what exactly it should do if it's not. Having to wrap all stderr write attempts with catches for this kind of thing seems a bit onerous to me, even for guis. Are we sure this isn't just a issue that should be addressed with the window manager? To be clear, I'm open to catching this in assword as you suggest, but I would like to understand the expectation for stderr (or stdout for that matter) availability. Just out of curiosity, what window manager are you using? jamie.
The reason my WM did not have stderr/stdout available is, I had started it from a terminal, disowned it, and then closed the terminal. So, stderr was pointing at /dev/pts/2, which had been deallocated. That's probably not an entirely original way to shoot oneself in the foot; I'm sure I've done that plenty of times before and just didn't try to run anything from the WM that expected to be able to write to stderr.