Red Hat Bugzilla – Bug 134437
Screen and dtach exit without error sending SIGHUP
Last modified: 2007-11-30 17:10:50 EST
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
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
detach -c /home/$USER/ ./$USER-server-bin global "$map" -nohomedir
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.
Feel free to ask.
After a day of searching I found this:
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.
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.)
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.
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
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.
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.