Re: [Lynx-dev] Strange behavior

[Bela Lubkin]

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<