I know when shell exits or itself receives SIGHUP, it will send SIGHUP to all background process.
'nohup cmd' or 'disown' will tell bash not to send SIGHUP. Is there a shell setting so that bash will always not send SIGHUP?
I want my backgroup process to run when bash got killed accidentally for various reasons.
Thanks.
Sounds like you might want to look into jobs and disown. https://www.gnu.org/software/bash/manual/html_node/Signals.html
Related
Consider this snippet as being saved in a file called snippet.sh:
nohup xmessage HI </dev/null &>/dev/null & disown
sleep 3
From the same directory, do xterm -e bash snippet.sh.
After 3 seconds, the xterm should disappear while the xmessage window lingers. All good and well. But what if the nohup is removed from the command in the snippet file? Then the xmessage which disappears along with the xterm. The bash documentation seems to indicate that disown should, by itself, be sufficient to prevent SIGHUP from being sent:
The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends
the SIGHUP to all jobs, running or stopped. Stopped jobs are sent SIGCONT to ensure that they
receive the SIGHUP. To prevent the shell from sending the signal to a particular job, it should be
removed from the jobs table with the disown builtin (see SHELL BUILTIN COMMANDS below) or marked to
not receive SIGHUP using disown -h.
So, the question is, why won't the xmessage window linger without nohup?
disown is sufficient to prevent the shell from sending the signal, but it doesn't stop anyone else.
In particular, the shell is the controlling process of the terminal with xmessage in its process group, and POSIX says that on exit:
If the process is a controlling process, the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process.
I'm trying to use a shell script to start a command. I don't care if/when/how/why it finishes. I want the process to start and run, but I want to be able to get back to my shell immediately...
You can just run the script in the background:
$ myscript &
Note that this is different from putting the & inside your script, which probably won't do what you want.
Everyone just forgot disown. So here is a summary:
& puts the job in the background.
Makes it block on attempting to read input, and
Makes the shell not wait for its completion.
disown removes the process from the shell's job control, but it still leaves it connected to the terminal.
One of the results is that the shell won't send it a SIGHUP(If the shell receives a SIGHUP, it also sends a SIGHUP to the process, which normally causes the process to terminate).
And obviously, it can only be applied to background jobs(because you cannot enter it when a foreground job is running).
nohup disconnects the process from the terminal, redirects its output to nohup.out and shields it from SIGHUP.
The process won't receive any sent SIGHUP.
Its completely independent from job control and could in principle be used also for foreground jobs(although that's not very useful).
Usually used with &(as a background job).
nohup cmd
doesn't hangup when you close the terminal. output by default goes to nohup.out
You can combine this with backgrounding,
nohup cmd &
and get rid of the output,
nohup cmd > /dev/null 2>&1 &
you can also disown a command. type cmd, Ctrl-Z, bg, disown
Alternatively, after you got the program running, you can hit Ctrl-Z which stops your program and then type
bg
which puts your last stopped program in the background. (Useful if your started something without '&' and still want it in the backgroung without restarting it)
screen -m -d $command$ starts the command in a detached session. You can use screen -r to attach to the started session. It is a wonderful tool, extremely useful also for remote sessions. Read more at man screen.
If I am working on a remote server (ssh) and I fork a process using bash & operator, will that process be killed if I am booted off the server due to server time-out? I'm pretty sure the answer is yes, but would love to know if there are any juicy details.
It might depend, but generally when you log out with your "connection program" (e.g. ssh in your case although it could have been rlogin or telnet as well), the shell and children (I think?) will receive a SIGHUP signal (hangup) which will make them terminate when you log out. There are two common ways to avoid this, running the program you want to keep running through nohup or screen. If the server have some other time limitation on running processes you will have to look into that.
bash will send a HUP signal to all background jobs. You can stop this from happening by starting the job with nohup (which should have a man page). If it's too late for nohup, you can use disown to stop the shell from sending a HUP to a job. disown is a builtin, so help disown will tell you everything you need to know.
I've seen monitoring programs either in scripts that check process status using 'ps' or 'service status(on Linux)' periodically, or in C/C++ that forks and wait on the process...
I wonder if it is possible to use bash with trap and restart the sub-process when SIGCLD received?
I have tested a basic suite on RedHat Linux with following idea (and certainly it didn't work...)
#!/bin/bash
set -o monitor # can someone explain this? discussion on Internet say this is needed
trap startProcess SIGCHLD
startProcess() {
/path/to/another/bash/script.sh & # the one to restart
while [ 1 ]
do
sleep 60
done
}
startProcess
what the bash script being started just sleep for a few seconds and exit for now.
several issues observed:
when the shell starts in foreground, SIGCHLD will be handled only once. does trap reset signal handling like signal()?
the script and its child seem to be immune to SIGINT, which means they cannot be stopped by ^C
since cannot be closed, I closed the terminal. The script seems to be HUP and many zombie children left.
when run in background, the script caused terminal to die
... anyway, this does not work at all. I have to say I know too little about this topic.
Can someone suggest or give some working examples?
Are there scripts for such use?
how about use wait in bash, then?
Thanks
I can try to answer some of your questions but not all based on what I
know.
The line set -o monitor (or equivalently, set -m) turns on job
control, which is only on by default for interactive shells. This seems
to be required for SIGCHLD to be sent. However, job control is more of
an interactive feature and not really meant to be used in shell scripts
(see also this question).
Also keep in mind this is probably not what you intended to do
because once you enable job control, SIGCHLD will be sent for every
external command that exists (e.g. every time you run ls or grep or
anything, a SIGCHLD will fire when that command completes and your trap
will run).
I suspect the reason the SIGCHLD trap only appears to run once is
because your trap handler contains a foreground infinite loop, so your
script gets stuck in the trap handler. There doesn't seem to be a point
to that loop anyways, so you could simply remove it.
The script's "immunity" to SIGINT seems to be an effect of enabling
job control (the monitor part). My hunch is with job control turned on,
the sub-instance of bash that runs your script no longer terminates
itself in response to a SIGINT but instead passes the SIGINT through to
its foreground child process. In your script, the ^C i.e. SIGINT
simply acts like a continue statement in other programming languages
case, since SIGINT will just kill the currently running sleep 60,
whereupon the while loop will immediately run a new sleep 60.
When I tried running your script and then killing it (from another
terminal), all I ended up with were two stray sleep processes.
Backgrounding that script also kills my shell for me, although
the behavior is not terribly consistent (sometimes it happens
immediately, other times not at all). It seems typing any keys other
than enter causes an EOF to get sent somehow. Even after the terminal
exits the script continues to run in the background. I have no idea
what is going on here.
Being more specific about what you want to accomplish would help. If
you just want a command to run continuously for the lifetime of your
script, you could run an infinite loop in the background, like
while true; do
some-command
echo some-command finished
echo restarting some-command ...
done &
Note the & after the done.
For other tasks, wait is probably a better idea than using job control
in a shell script. Again, it would depend on what exactly you are trying
to do.
According to this faq (and by many other books):
ftp://rtfm.mit.edu/pub/faqs/unix-faq/programmer/faq
1.15 Why doesn't my process get SIGHUP when its parent dies?
SIGHUP won't be sent to background processes when none of them is " stopped ".
but we all know that if SIGHUP isn't captured in background processes, they will die when you close the terminal(or connection like ssh).
i.e. CTRL+Z - bg isn't enough for a process to survive when terminal is closed.
But why?
Any wisdom is appreciated!
There is an easy solution for it. Use nohup before running the command.
After googling a bit.
I assume the HUP signal which result in exiting of background processes is from shell.
Here are the steps:
Terminal is closed, bash receives SIGHUP from kernel(driver)
Bash exits by default upon receipt of a SIGHUP. Before exiting, it resends the SIGHUP to all jobs, running or stopped
All jobs, including background processes, exit if they don't capture SIGHUP