Closed
Bug 151737
Opened 23 years ago
Closed 23 years ago
freeze on shell suspend/resume in background
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: rockear-bugzilla, Assigned: Matti)
Details
(Keywords: qawanted)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.1a) Gecko/20020610
BuildID: 2002061108
I run mozilla on a faster computer than mine through a ssh X11 tunnel. If
mozilla is started in the foreground from an Xterm, suspending the process with
^Z, then resuming it in the background with %1&, causes mozilla to irrevokably
lock up.
Reproducible: Always
Steps to Reproduce:
1. Install moz on a remote host. Make sure X11 forwarding is turned on in sshd.conf.
2. From an Xterm on your host: ssh remote-host mozilla
3. When moz is up, switch back to the Xterm and ^Z
4. Move the suspended moz to the background: %1&
5. Try to switch back into moz.
Actual Results: Total lock. Other than the window manager borders, moz's
content area will not repaint, and no events will register.
Xserver: XFree86 4.1.0 debian, on a powerpc 601 (PowerMac 7200/75). The remote
Mozilla is running on a Red Hat 7.1 x586. No GNOME or KDE -- a 75 mhz 601 is
too slow! -- just naked X11 and a window manager (FVWM 2.4.7). ssh 3.0.2p1.
Workaround very easy -- don't throw it in the background!
Assignee | ||
Comment 1•23 years ago
|
||
-> Remote ?
Assignee: Matti → blizzard
Component: Browser-General → X-remote
QA Contact: imajes-qa → blizzard
Comment 2•23 years ago
|
||
No, not X remote. (X-remote means loading web pages through X protocol
commands, i.e. using netscape -remote or mozilla -remote, not displaying to a
remote X server.)
Assignee: blizzard → Matti
Component: X-remote → Browser-General
Reporter | ||
Comment 3•23 years ago
|
||
Hey folks, I have some additional details about how to trigger this. I
downloaded the latest nightly build (linux-ppc, 2002061205) and verified that it
does NOT occur when running locally, only when being forwarded over a ssh
connection. Here's precisely what happens (also with the latest nightly build
on the remote side, linux-i586, 2002061421):
slimedevil 11% ssh nightsider m/mozilla
zsh: suspended ssh nightsider m/mozilla
slimedevil 12% %1&
[1] - continued ssh nightsider m/mozilla
slimedevil 13% scan +bugzil
[1] + suspended (tty input) ssh nightsider m/mozilla
The important point is you need to do something, /anything/, in the shell after
moz has been moved to the background, it even interrupted my typing in the above
example. It's suspended itself, but there's no way to get its attention after
this short of "kill -HUP %1" or destroying the window manually.
Comment 4•23 years ago
|
||
do you also see this if you do:
$ ssh nightsider
$ mozilla
^Z
$ %1&
$ exit
I think I've done that a few times myself without problems. What version of ssh
are you running? OpenSSH? What it sounds like is that ssh doesn't like being
put in the background (rather than mozilla). You might try:
$ ssh nightsider xlock
^Z
$ %1&
that works for me with ssh-3.1.2 (from www.ssh.com)
Reporter | ||
Comment 5•23 years ago
|
||
OpenSSH 3.0.2p1 on both sides.
Your first suggestion works perfectly, and in view of your explanation, I bet
you're right; ssh just can't cope with being backgrounded. Didn't know that.
Darn it, and I was so *sure* I'd found a bug ^_^
Thanks for the help.
Comment 6•23 years ago
|
||
$ ssh localhost xclock & (xclock comes up)
$ (type anything)
[1] + Suspended (tty input) ssh localhost xclock
marking INVALID
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•