Bug 134437
| Summary: | Screen and dtach exit without error sending SIGHUP | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | -M <callihn> |
| Component: | screen | Assignee: | Daniel Reed <djr> |
| Status: | CLOSED NOTABUG | QA Contact: | Brock Organ <borgan> |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-10-09 02:49:15 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
-M
2004-10-02 18:09:50 UTC
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. |