Tom Masterson wrote: > I am using Ubuntu 18.04 (Bionic Beaver) and among other things I am > running brltty as I am blind. When running lynx under a virtual console > (say tty3) if I switch to another console using ctrl-alt-function > (ctrl-alt-f4) and then switch back to lynx the computer has closed lynx. > The only thing I have been able to find is if I do a -trace the trace file > shows a GETCH0 got 0xffffffff just before lynx closed down. It appears to > be a normal shutdown. This occurs with the packaged build of 2.8.9dev.16 > or a built version of 2.9.0dev.1. > > I have not seen this in previous versions of Ubuntu or other distros. Any > ideas where I should look to figure out why this is happening?
As Thorsten Glaser said, this is exactly how it would behave if it received a legitimate EOF. Here are a few troubleshooting steps I would take, and then where to go next would depend on results. Thet're in the order I thought of them, not necessarily best order to try them... 1. Question: does Lynx die (exit) when you switch away, or switch back? Use `ps` to check. Crudely, `ps --no-headers -C lynx | wc -l` will output how many Lynx processes are running. While Lynx is running, switch away and run that. Switch back and run it again (at the new command line after Lynx died). If they're the same (even nonzero), Lynx died on switch-away; if different by 1, on the switch-back. Significance: dying on switch-away suggests some sort of spurious input character issued by the switch-away keyboard sequence. Dying on switch-back suggests some sort of signal or plumbing issue, possibly in the console driver. 2. Do any unexpected processes have your tty open? Check this before starting Lynx. Run `lsof $(tty)`. Explain any unexpected outputs. Example: I just added a new tab to my running `mate-terminal` (ctrl-shift-t). `lsof $(tty)` there showed 3x `bash` (my running shell's stdin/out/err); 3x `lsof` (itself); 1x `mate-terminal` (not sure why it still has the slave side of the pty open, but it's not entirely unexpected, and it has the pty of every other tab open as well -- along with the expected N times /dev/ptmx). Nothing else. Significance: some other process could be doing something to trigger an EOF (e.g.: changing stdio settings like vmin & vtime). Why it would do that on vty switching is a mystery, but any other processes would be suspicious. Explain them, or kill (or `kill -STOP`) them before doing a test switch-away. Of course killing or suspending unexplained processes may have its own weird effects. But assuming not, if this allows a switch / switch-back to happen without killing Lynx, focus on those other process(es). 3. Run Lynx under `strace`. e.g. `strace -f -tt -o /tmp/lynx.trace lynx`. "-f" to catch child processes; "-tt" to timestamp the lines, which might show whether it happens on switch-away or switch-back, or other insights. Other flags might be useful. Once running, pause a few seconds; switch away; pause a few seconds; switch back. The pauses are to make the timestamps tell a clear story. What happens in the trace when Lynx dies? 4. What if you switch away to a different vty (ctrl-alt-F5)? Maybe it's something bad about the specific vty you've been targeting. Maybe the console stupidly injects an extra ctrl-D when you hit ctrl-alt-F4, but not for other vtys' switch sequences. This is improbable but so easy to test... Also try switching to a vty which has nothing running on it (if any). Maybe it's some misbehavior of whatever are taking the roles of getty, login, and shell, running on the switched-to vty (very unlikely but still easy to test). 5. Suppose you aren't running Lynx, but something simpler? e.g., if I run: $ bash $ read foo _ it's waiting for me to type something and hit Enter ... I hit ctrl-D $ -- shell prompt returned So, start a simple "read foo" (under `bash`, because I'm not 100% confident other shells will behave identically). Switch away; switch back. Did it return to the prompt? ... Essentially nothing about this has to do with Lynx, just some oddity on your system. Feel free to reply directly to me if you want to pursue some sort of additional troubleshooting and don't want to burden the list. (OTOH, list members might want to be in the loop; I'm not sure what the proper etiquette is in such a case.) >Bela< _______________________________________________ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev