Jerry Feldman wrote:
On 12/29/2008 04:56 PM, ƽÌ캫 wrote:
2008/12/30, Jerry Feldman <gaf@xxxxxxx>:
On 12/29/2008 10:05 AM, ƽÌ캫 wrote:
hi,
It seems that when I logout from the console, the background process
doesn't get HUP signal:
{ trap "echo Ignore HUP >>/tmp/trap.out" 1; while sleep 3;do echo
hello >>/tmp/hello.txt;done; }&
And it seems it will become a daemon and run forever until rebooting.
Is this correct? Why it didn't get HUP signal?
Thanks!
Are you running this from a terminal window?
I am running this in tty2, a console. I just type those into the
console and run it, then logout.
Are you possibly setting nohup in your environment.
It seems it is. But how?
Are you typing the above commands directly? What happens if you place
these into a script and run the script in the background?
There are a number of things that can cause a shell script to ignore the
HUP signal. I tested this as a script on an Ubuntu laptop, and it
behaved the same as yours:
The process remained. So the issue is not that exiting the parent
process (GNOME Term) or logging out of GNOME fails to issue a HUP, it is
that the process itself ignores the HUP signal since I sent a "kill -HUP
<pid>" to the process.
If you simply send the HUP signal, you will see that "Ignore HUP" will
appear in /tmp/trap.out".
I have the same results with you.
The signal(1) command is probably the culprit, though the man pages are
vague.
I suspect of that maybe the logout doesn't send out HUP to these
background processes?
After looking at this again now that I understand the specific issue. I
would agree.
By default, the "huponexit" option is NOT set on bash shells, so a
terminating interactive shell does NOT send HUPs to background
processes.
Try it again, but run "shopt -s huponexit" before executing the
background process. When you log out, HUPs should be sent to child
processes.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks@xxxxxxxx -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- Do not taunt the sysadmins, for they are subtle and quick to anger -
----------------------------------------------------------------------
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
