On Mon, 22 Jul 2013, Trent W. Buck wrote:
Tim Connors wrote:
I like the twb-loop. I had been running fvwm for 5 years without a crash.
Ah, well, that was back in the days when ratpoison actually crashed a lot, and when I was actually patching in new features. Hasn't been an issue for me for at least five years.
Heh, cross pollination: http://rather.puzzling.org/~tconnors/code/keepfvwmalive (and other dependent scripts in that directory) alternate between fvwm and twm, timestamp and dedup .xsession-errors. Also funges an NFS automounted home directory if the mount goes stale. (and good old sleep 1. don't recall what the story was behind that, but probably similar to yours) Don't use SIGTERM or SIGINT if you want to forcefully restart fvwm. It exits with error code 0! You can reliably use SIGUSR1 in the latest wheezy version to restart fvwm to reread its config file (recently, there was still a bug where the handler only worked once. after a restart, the USR1 handler wasn't reset, and it would invoke the default crash handler). Heck, I can even convince fvwm to invoke my own handler to regenerate the config file prior to restarting. That's if fvwm is still in a working state. So the only case left is restarting fvwm upon crash or lockup. The comments seem to suggest I found a way of getting fvwm to generate its ~/.fs-restart state file so windows are moved back to where they were prior to crash, but the code suggests I didn't actually manage to write that part. Woops. I was probably hoping for a signal handler in fvwm that would do that for me. -- Tim Connors