Hide Forgot
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.
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.
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 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.
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.