Bug 134437 - Screen and dtach exit without error sending SIGHUP
Screen and dtach exit without error sending SIGHUP
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: screen (Show other bugs)
2
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Daniel Reed
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-02 14:09 EDT by -M
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-08 22:49:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description -M 2004-10-02 14:09:50 EDT
Description of problem:

Screen and detach exit without error

Version-Release number of selected component (if applicable):

Screen version 4.00.02 (FAU) 5-Dec-03

How reproducible:

Attempting to run an America's Army (http://www.americasarmy.com) game
server using screen which worked fine in Fedora Core 1 using the command:

 screen -A -m -d -S $USER-AA ./$USER-server-bin global "$map"
-nohomedir -multihome=$serverip -INI=$ini

or

detach -c /home/$USER/ ./$USER-server-bin global "$map" -nohomedir
-multihome=$serverip -INI=$ini

Where all varibles have been supplied by the script being used as a
login shell and the user is known to the system now fails under Fedora
Core 2, screen and detach now exit with no errors given as soon as the
server is started and stops putting output on the screen. The only
changes have been from Core 1 to Core 2. Trying an older version of
screen produces the same results or lack thereof.
  
Additional info:

Feel free to ask.
Comment 1 -M 2004-10-02 17:11:42 EDT
After a day of searching I found this:

http://www.unrealadmin.org/forums/showthread.php?t=6859

Here is the short:

Screen is sending SIGHUP

The work around I have found to work is:

screen <options> sh -c "./command <options>; sleep 30" &

Adding sh -c "; sleep 30" &

Why is beyond be, but this is the only way I could get it to work.
Comment 2 Daniel Reed 2004-10-08 13:19:04 EDT
When screen is started with the options -d, -m, and -S, it starts in
daemon mode instead of interactive mode.

Remove -d from your list of options, or note that your existing
command *does* start up a screen session, it just starts it in a
detached state. (To get into the screen session, just run "screen -r"
after the initial screen command.)
Comment 3 -M 2004-10-08 17:56:33 EDT
I know what the options do as it is well documented in the manual and
no as I have already said IT IS STARTING it, however unless it sleeps
for thirty seconds it dies from a SIGHUP, apparently sent to screen,
by screen as this issue DID NOT exist in Fedora Core 1, running the
same command on the same program. The issue exists only in Fedora Core
2 and it exists rather screen is detached or not. Now if you will read
what I have supplied and check it yourself, instead of assuming
everyone else on this planet is an idiot, then we would get a lot
further a lot faster. ;)

Try reading the bug, no where did I screen doesn't start.
Comment 4 Daniel Reed 2004-10-08 18:22:07 EDT
Try running the command:

screen -dmS test /bin/tcsh
screen -r test

You should be inside a screen session running tcsh.

Hit the key sequence ^A d and you will be returned to your original
command prompt.

Run the command "ps xf" and find the instance of /bin/tcsh running
under SCREEN. If it shows up as:
  24006 ?        Ss     0:00 SCREEN -dmS test /bin/tcsh
  24007 pts/1    Ss+    0:00  \_ -bin/tcsh
its pid is 24007.

Run the command "kill -HUP 24007" where 24007 is the pid you got from
"ps xf". Run the command "screen -r test" and it should tell you there
is no screen to resume; this is because the SIGHUP signal you sent
caused /bin/tcsh to exit, taking the SCREEN master with it.

screen -dmS X command does not cause SIGHUP to be sent. There may be
something wrong with your specific setup, but it does not appear to be
a generic screen problem, nor a problem with our packaging.

If you continue to see this problem, please provide a test case that
only uses software we distribute (such as /bin/tcsh or some other
interactive program); thanks.
Comment 5 Daniel Reed 2004-10-08 22:49:15 EDT
Open bugs only help developers and testers track issues they are
planning to address. I do not believe this bug represents an issue to
address, so this bug should not be open.

Please leave this bug closed until you can provide a test case that
demonstrates any misbehavior.

Thanks.

Note You need to log in before you can comment on or make changes to this bug.