Exact same behavior as #260 I ran into an issue where saving the wallpaper would just hang for an indeterminate period of time (macOS). Digging into it further I found that I had pushed my system into a weird state where there were some /dev/ttys00* file descriptors that existed but were not attached to any process or actual tty.

cating any data to them would hang and force me to quit. Interestingly enough, who listed these as old and inactive (indicating that /var/run/utmpx knows about them, but the system is not cleaning them up for whatever reason):

A regular who shows only the active sessions:

havulv-mbp:~ havulv$ who
havulv console  Mar 12 06:16
havulv ttys000  Apr  6 10:26
havulv ttys002  Apr  6 11:09
havulv ttys005  Apr  6 11:16

Listing all of them shows exited terminals with the file descriptors still hanging around in /dev/

havulv-mbp:~ havulv$ who -a
reboot    ~        Mar 12 06:15 00:04 	     1
havulv console  Mar 12 06:16  old  	   103
havulv ttys000  Apr  6 10:26 00:05 	   554
havulv ttys001  Apr  6 11:14   .   	  6005	term=0 exit=0
havulv ttys002  Apr  6 11:09 00:05 	  4901
havulv ttys003  Mar 27 12:08  old  	 35702	term=0 exit=0
havulv ttys004  Mar 17 13:13  old  	 16586	term=0 exit=0
havulv ttys005  Apr  6 11:16   .   	  8244
havulv ttys006  Mar 25 09:34   .   	 27105	term=0 exit=0
havulv ttys007  Apr  6 10:18   .   	 98616	term=0 exit=0

The try-except block won't catch this, as Python will happily try to pump data into the file as a blocking operation (and there is not timeout thread to stop it) because it does not know that the tty is effectively dead.

As a workaround, there should be a flag to only send sequence data to active ttys (which can be determined by who, continuing with the tty if who is not available to subprocess). This is kind of an edge case and, I think, represents a not good state of the system, so it probably should not be on by default.