Why nohup background process is getting killed?
Clash Royale CLAN TAG#URR8PPP
up vote
8
down vote
favorite
I tried starting a shell script via a remote session, which starts a process in the background using the command.
nohup python3 run.py > nohup.out &
When the remote session is closed, the process is getting killed with the message:
Caught signal SIGHUP
SIGHUP caught but not daemonized. Exiting.
I don't understand; why is the process getting killed when it was started in background using nohup &?
background-process nohup
edited Jun 3 at 11:14
Jeff Schaller
31k846105
asked May 29 at 7:25
Mostwanted Mani
1456
add a comment |Â
up vote
8
down vote
favorite
I tried starting a shell script via a remote session, which starts a process in the background using the command.
nohup python3 run.py > nohup.out &
When the remote session is closed, the process is getting killed with the message:
Caught signal SIGHUP
SIGHUP caught but not daemonized. Exiting.
I don't understand; why is the process getting killed when it was started in background using nohup &?
background-process nohup
edited Jun 3 at 11:14
Jeff Schaller
31k846105
asked May 29 at 7:25
Mostwanted Mani
1456
1
I used to be confused by all the unexpected behavior of shell job control. Now I just usetmuxand ignorenohupor disown or background task completely.
– Siyuan Ren
May 29 at 13:30
add a comment |Â
up vote
8
down vote
favorite
up vote
8
down vote
favorite
I tried starting a shell script via a remote session, which starts a process in the background using the command.
nohup python3 run.py > nohup.out &
When the remote session is closed, the process is getting killed with the message:
Caught signal SIGHUP
SIGHUP caught but not daemonized. Exiting.
I don't understand; why is the process getting killed when it was started in background using nohup &?
background-process nohup
edited Jun 3 at 11:14
Jeff Schaller
31k846105
asked May 29 at 7:25
Mostwanted Mani
1456
I tried starting a shell script via a remote session, which starts a process in the background using the command.
nohup python3 run.py > nohup.out &
When the remote session is closed, the process is getting killed with the message:
Caught signal SIGHUP
SIGHUP caught but not daemonized. Exiting.
I don't understand; why is the process getting killed when it was started in background using nohup &?
background-process nohup
edited Jun 3 at 11:14
Jeff Schaller
31k846105
asked May 29 at 7:25
Mostwanted Mani
1456
edited Jun 3 at 11:14
Jeff Schaller
31k846105
edited Jun 3 at 11:14
Jeff Schaller
31k846105
edited Jun 3 at 11:14
Jeff Schaller
31k846105
31k846105
asked May 29 at 7:25
Mostwanted Mani
1456
asked May 29 at 7:25
Mostwanted Mani
1456
asked May 29 at 7:25
Mostwanted Mani
1456
1456
1
I used to be confused by all the unexpected behavior of shell job control. Now I just usetmuxand ignorenohupor disown or background task completely.
– Siyuan Ren
May 29 at 13:30
add a comment |Â
1
I used to be confused by all the unexpected behavior of shell job control. Now I just usetmuxand ignorenohupor disown or background task completely.
– Siyuan Ren
May 29 at 13:30
1
1
I used to be confused by all the unexpected behavior of shell job control. Now I just use
tmux and ignore nohup or disown or background task completely.– Siyuan Ren
May 29 at 13:30
I used to be confused by all the unexpected behavior of shell job control. Now I just use
tmux and ignore nohup or disown or background task completely.– Siyuan Ren
May 29 at 13:30
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
10
down vote
accepted
Your Python program undoes nohup.
nohup ignores the hangup signal with SIG_IGN and then chain loads your program in the same process.
Your Python program promptly resets the signal handling for the hangup signal, installing its own signal handler. That handler checks an internal function (that is not designed very well, being based upon some flawed assumptions, if it is the one that I have seen) and decides that the appropriate course of action on receipt of a hangup signal is to print that message and exit.
Your Python program by design is not nohup-able. On a system with a job control shell and POSIX session/job semantics, you need to be disowning the job so that the shell never knows about it to send a hangup signal to it in the first place.
(Even that is not enough on systemd operating systems. Because the systemd people have made a bit of a pig's ear of their user-space login session mechanism, you also need to ensure that systemd's mechanism that signals system shutdown, rather than hangup, to login sessions at every logout is also not kicking in.)
Further reading
- https://docs.cherrypy.org/en/latest/_modules/cherrypy/process/plugins.html
- Does nohup try to arrange for the program not to have a controlling terminal?
- Difference between nohup, disown and &
- When tmux exits (closes pty master), background processes from startup scripts die — why?
- https://unix.stackexchange.com/a/310775/5132
- https://unix.stackexchange.com/a/379264/5132
answered May 29 at 8:21
JdeBP
28k459133
3
Is it their Python program that does it, or is it the Python interpreter (/run-time environment) that does it silently behind their back?
– ilkkachu
May 29 at 8:29
Also, on Mac OS, logging out from an ssh session kills you shell jobs, even when started usingnohup; haven't found a remedy for it
– imhotap
May 29 at 9:47
Well, if the problem is the signal handler the OP could simply change the signal handler to an handler that does not kill the process. This should work independently of who installs such signal handler. I'd like to add regarding ssh: sometimes, even if the process is kept alive, it might have troubles. A couple years ago I lost quite some time trying to understand some permission errors and, in the end, the culprit was Kerberos: when the ssh session was closed the tokens were expired, so I had to create new tokens to be used instead of those of the ssh session.
– Bakuriu
May 29 at 12:14
@JdeBP I triedsetsid nohup python3 run.py > nohup.out &, setsid has resolved this issue. Is this a proper approach?
– Mostwanted Mani
Jun 1 at 13:45
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
10
down vote
accepted
Your Python program undoes nohup.
nohup ignores the hangup signal with SIG_IGN and then chain loads your program in the same process.
Your Python program promptly resets the signal handling for the hangup signal, installing its own signal handler. That handler checks an internal function (that is not designed very well, being based upon some flawed assumptions, if it is the one that I have seen) and decides that the appropriate course of action on receipt of a hangup signal is to print that message and exit.
Your Python program by design is not nohup-able. On a system with a job control shell and POSIX session/job semantics, you need to be disowning the job so that the shell never knows about it to send a hangup signal to it in the first place.
(Even that is not enough on systemd operating systems. Because the systemd people have made a bit of a pig's ear of their user-space login session mechanism, you also need to ensure that systemd's mechanism that signals system shutdown, rather than hangup, to login sessions at every logout is also not kicking in.)
Further reading
- https://docs.cherrypy.org/en/latest/_modules/cherrypy/process/plugins.html
- Does nohup try to arrange for the program not to have a controlling terminal?
- Difference between nohup, disown and &
- When tmux exits (closes pty master), background processes from startup scripts die — why?
- https://unix.stackexchange.com/a/310775/5132
- https://unix.stackexchange.com/a/379264/5132
answered May 29 at 8:21
JdeBP
28k459133
3
Is it their Python program that does it, or is it the Python interpreter (/run-time environment) that does it silently behind their back?
– ilkkachu
May 29 at 8:29
Also, on Mac OS, logging out from an ssh session kills you shell jobs, even when started usingnohup; haven't found a remedy for it
– imhotap
May 29 at 9:47
Well, if the problem is the signal handler the OP could simply change the signal handler to an handler that does not kill the process. This should work independently of who installs such signal handler. I'd like to add regarding ssh: sometimes, even if the process is kept alive, it might have troubles. A couple years ago I lost quite some time trying to understand some permission errors and, in the end, the culprit was Kerberos: when the ssh session was closed the tokens were expired, so I had to create new tokens to be used instead of those of the ssh session.
– Bakuriu
May 29 at 12:14
@JdeBP I triedsetsid nohup python3 run.py > nohup.out &, setsid has resolved this issue. Is this a proper approach?
– Mostwanted Mani
Jun 1 at 13:45
add a comment |Â
up vote
10
down vote
accepted
Your Python program undoes nohup.
nohup ignores the hangup signal with SIG_IGN and then chain loads your program in the same process.
Your Python program promptly resets the signal handling for the hangup signal, installing its own signal handler. That handler checks an internal function (that is not designed very well, being based upon some flawed assumptions, if it is the one that I have seen) and decides that the appropriate course of action on receipt of a hangup signal is to print that message and exit.
Your Python program by design is not nohup-able. On a system with a job control shell and POSIX session/job semantics, you need to be disowning the job so that the shell never knows about it to send a hangup signal to it in the first place.
(Even that is not enough on systemd operating systems. Because the systemd people have made a bit of a pig's ear of their user-space login session mechanism, you also need to ensure that systemd's mechanism that signals system shutdown, rather than hangup, to login sessions at every logout is also not kicking in.)
Further reading
- https://docs.cherrypy.org/en/latest/_modules/cherrypy/process/plugins.html
- Does nohup try to arrange for the program not to have a controlling terminal?
- Difference between nohup, disown and &
- When tmux exits (closes pty master), background processes from startup scripts die — why?
- https://unix.stackexchange.com/a/310775/5132
- https://unix.stackexchange.com/a/379264/5132
answered May 29 at 8:21
JdeBP
28k459133
3
Is it their Python program that does it, or is it the Python interpreter (/run-time environment) that does it silently behind their back?
– ilkkachu
May 29 at 8:29
Also, on Mac OS, logging out from an ssh session kills you shell jobs, even when started usingnohup; haven't found a remedy for it
– imhotap
May 29 at 9:47
Well, if the problem is the signal handler the OP could simply change the signal handler to an handler that does not kill the process. This should work independently of who installs such signal handler. I'd like to add regarding ssh: sometimes, even if the process is kept alive, it might have troubles. A couple years ago I lost quite some time trying to understand some permission errors and, in the end, the culprit was Kerberos: when the ssh session was closed the tokens were expired, so I had to create new tokens to be used instead of those of the ssh session.
– Bakuriu
May 29 at 12:14
@JdeBP I triedsetsid nohup python3 run.py > nohup.out &, setsid has resolved this issue. Is this a proper approach?
– Mostwanted Mani
Jun 1 at 13:45
add a comment |Â
up vote
10
down vote
accepted
up vote
10
down vote
accepted
Your Python program undoes nohup.
nohup ignores the hangup signal with SIG_IGN and then chain loads your program in the same process.
Your Python program promptly resets the signal handling for the hangup signal, installing its own signal handler. That handler checks an internal function (that is not designed very well, being based upon some flawed assumptions, if it is the one that I have seen) and decides that the appropriate course of action on receipt of a hangup signal is to print that message and exit.
Your Python program by design is not nohup-able. On a system with a job control shell and POSIX session/job semantics, you need to be disowning the job so that the shell never knows about it to send a hangup signal to it in the first place.
(Even that is not enough on systemd operating systems. Because the systemd people have made a bit of a pig's ear of their user-space login session mechanism, you also need to ensure that systemd's mechanism that signals system shutdown, rather than hangup, to login sessions at every logout is also not kicking in.)
Further reading
- https://docs.cherrypy.org/en/latest/_modules/cherrypy/process/plugins.html
- Does nohup try to arrange for the program not to have a controlling terminal?
- Difference between nohup, disown and &
- When tmux exits (closes pty master), background processes from startup scripts die — why?
- https://unix.stackexchange.com/a/310775/5132
- https://unix.stackexchange.com/a/379264/5132
answered May 29 at 8:21
JdeBP
28k459133
Your Python program undoes nohup.
nohup ignores the hangup signal with SIG_IGN and then chain loads your program in the same process.
Your Python program promptly resets the signal handling for the hangup signal, installing its own signal handler. That handler checks an internal function (that is not designed very well, being based upon some flawed assumptions, if it is the one that I have seen) and decides that the appropriate course of action on receipt of a hangup signal is to print that message and exit.
Your Python program by design is not nohup-able. On a system with a job control shell and POSIX session/job semantics, you need to be disowning the job so that the shell never knows about it to send a hangup signal to it in the first place.
(Even that is not enough on systemd operating systems. Because the systemd people have made a bit of a pig's ear of their user-space login session mechanism, you also need to ensure that systemd's mechanism that signals system shutdown, rather than hangup, to login sessions at every logout is also not kicking in.)
Further reading
- https://docs.cherrypy.org/en/latest/_modules/cherrypy/process/plugins.html
- Does nohup try to arrange for the program not to have a controlling terminal?
- Difference between nohup, disown and &
- When tmux exits (closes pty master), background processes from startup scripts die — why?
- https://unix.stackexchange.com/a/310775/5132
- https://unix.stackexchange.com/a/379264/5132
answered May 29 at 8:21
JdeBP
28k459133
edited May 29 at 8:35
answered May 29 at 8:21
JdeBP
28k459133
answered May 29 at 8:21
JdeBP
28k459133
answered May 29 at 8:21
JdeBP
28k459133
28k459133
3
Is it their Python program that does it, or is it the Python interpreter (/run-time environment) that does it silently behind their back?
– ilkkachu
May 29 at 8:29
Also, on Mac OS, logging out from an ssh session kills you shell jobs, even when started usingnohup; haven't found a remedy for it
– imhotap
May 29 at 9:47
Well, if the problem is the signal handler the OP could simply change the signal handler to an handler that does not kill the process. This should work independently of who installs such signal handler. I'd like to add regarding ssh: sometimes, even if the process is kept alive, it might have troubles. A couple years ago I lost quite some time trying to understand some permission errors and, in the end, the culprit was Kerberos: when the ssh session was closed the tokens were expired, so I had to create new tokens to be used instead of those of the ssh session.
– Bakuriu
May 29 at 12:14
@JdeBP I triedsetsid nohup python3 run.py > nohup.out &, setsid has resolved this issue. Is this a proper approach?
– Mostwanted Mani
Jun 1 at 13:45
add a comment |Â
3
Is it their Python program that does it, or is it the Python interpreter (/run-time environment) that does it silently behind their back?
– ilkkachu
May 29 at 8:29
Also, on Mac OS, logging out from an ssh session kills you shell jobs, even when started usingnohup; haven't found a remedy for it
– imhotap
May 29 at 9:47
Well, if the problem is the signal handler the OP could simply change the signal handler to an handler that does not kill the process. This should work independently of who installs such signal handler. I'd like to add regarding ssh: sometimes, even if the process is kept alive, it might have troubles. A couple years ago I lost quite some time trying to understand some permission errors and, in the end, the culprit was Kerberos: when the ssh session was closed the tokens were expired, so I had to create new tokens to be used instead of those of the ssh session.
– Bakuriu
May 29 at 12:14
@JdeBP I triedsetsid nohup python3 run.py > nohup.out &, setsid has resolved this issue. Is this a proper approach?
– Mostwanted Mani
Jun 1 at 13:45
3
3
Is it their Python program that does it, or is it the Python interpreter (/run-time environment) that does it silently behind their back?
– ilkkachu
May 29 at 8:29
Is it their Python program that does it, or is it the Python interpreter (/run-time environment) that does it silently behind their back?
– ilkkachu
May 29 at 8:29
Also, on Mac OS, logging out from an ssh session kills you shell jobs, even when started using
nohup; haven't found a remedy for it– imhotap
May 29 at 9:47
Also, on Mac OS, logging out from an ssh session kills you shell jobs, even when started using
nohup; haven't found a remedy for it– imhotap
May 29 at 9:47
Well, if the problem is the signal handler the OP could simply change the signal handler to an handler that does not kill the process. This should work independently of who installs such signal handler. I'd like to add regarding ssh: sometimes, even if the process is kept alive, it might have troubles. A couple years ago I lost quite some time trying to understand some permission errors and, in the end, the culprit was Kerberos: when the ssh session was closed the tokens were expired, so I had to create new tokens to be used instead of those of the ssh session.
– Bakuriu
May 29 at 12:14
Well, if the problem is the signal handler the OP could simply change the signal handler to an handler that does not kill the process. This should work independently of who installs such signal handler. I'd like to add regarding ssh: sometimes, even if the process is kept alive, it might have troubles. A couple years ago I lost quite some time trying to understand some permission errors and, in the end, the culprit was Kerberos: when the ssh session was closed the tokens were expired, so I had to create new tokens to be used instead of those of the ssh session.
– Bakuriu
May 29 at 12:14
@JdeBP I tried
setsid nohup python3 run.py > nohup.out &, setsid has resolved this issue. Is this a proper approach?– Mostwanted Mani
Jun 1 at 13:45
@JdeBP I tried
setsid nohup python3 run.py > nohup.out &, setsid has resolved this issue. Is this a proper approach?– Mostwanted Mani
Jun 1 at 13:45
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f446625%2fwhy-nohup-background-process-is-getting-killed%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
1
I used to be confused by all the unexpected behavior of shell job control. Now I just use
tmuxand ignorenohupor disown or background task completely.– Siyuan Ren
May 29 at 13:30