When you close a GNOME Terminal window, a SIGHUP is sent to the shell that it was running. The shell will typically send a SIGHUP to every process group that it knows it created - even ones started with nohup
- and then exit. If the shell is bash
, it will skip sending a SIGHUP to any process group that the user marked with disown
.
Running a command with nohup
makes it ignore SIGHUP, but the process can change that. When the disposition of SIGHUP for a process is the default, then if it receives a SIGHUP, the process will be terminated.
Linux provides some tools to examine a running process's signal settings.
The chromium-browser shell script does an exec
of the compiled app, so its process ID remains the same. So to see its signal settings, I ran nohup chromium-browser &
and then looked at /proc/$!/status
to see the signal disposition.
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000180014003
Those are hex numbers. This shows that SIGHUP is not caught and is not ignored. Only SIGPIPE (the 13th bit in SigIgn) is ignored. I traced this to the following code:
// Setup signal-handling state: resanitize most signals, ignore SIGPIPE.
void SetupSignalHandlers() {
// Sanitise our signal handling state. Signals that were ignored by our
// parent will also be ignored by us. We also inherit our parent's sigmask.
sigset_t empty_signal_set;
CHECK(0 == sigemptyset(&empty_signal_set));
CHECK(0 == sigprocmask(SIG_SETMASK, &empty_signal_set, NULL));
struct sigaction sigact;
memset(&sigact, 0, sizeof(sigact));
sigact.sa_handler = SIG_DFL;
static const int signals_to_reset[] =
{SIGHUP, SIGINT, SIGQUIT, SIGILL, SIGABRT, SIGFPE, SIGSEGV,
SIGALRM, SIGTERM, SIGCHLD, SIGBUS, SIGTRAP}; // SIGPIPE is set below.
for (unsigned i = 0; i < arraysize(signals_to_reset); i++) {
CHECK(0 == sigaction(signals_to_reset[i], &sigact, NULL));
}
// Always ignore SIGPIPE. We check the return value of write().
CHECK(signal(SIGPIPE, SIG_IGN) != SIG_ERR);
}
Despite the comment, signals ignored by the parent are not being ignored. A SIGHUP will kill chromium.
The workaround is to do what @xx4h points out: use the disown
command in your bash so that, if bash has to exit, it does not send SIGHUP to the chromium-browser
process group. You can write a function to do this:
mychromium () { /usr/bin/chromium-browser & disown $!; }
Best Answer
It's a little hard to diagnose, as you don't give source for
myproc
, but I suspect that your problem has something to do with "controlling TTY". I wrote a small shell script that just callssleep 100
. I ran it undernohup
:If you look at the
ps
output, you see a column named "TTY". At least some versions ofnohup
(the one I used above is from GNU coreutils, version 5.97, so relatively old). When I exited the bash shell from which I startedsleeper
, the TTY column changed to '?', meaning thatsleeper
didn't have one.If
myproc
doesn't deliberately detach itself from it's controlling TTY, it's still possible to get things like a SIGPIPE signal if it tries to write to stdout. It seems to me other things are possible, but I can't recall or google anything up.If you can find or compile "daemonize", you might want to try it. If
myproc
is compiled, you could modify the source to call thedaemon(3)
library function.