Process started by script does not receive SIGINT
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I am on Ubuntu 16.04.5 LTS (AWS)
I am creating a python process via this command:nohup python -u main.py > nohup.out 2>&1 &
I would like to send a ctrl-c/SIGINT to the process, so I send kill -2 <pid>.
When I start the process from my terminal, this works fine, the program receives the keyboard interrupt and closes gracefully.
When I start the process via a .sh script or via another bash process (e.g. bash -c 'nohup python -u main.py > nohup.out 2>&1 &'). (I believe both methods start the process in the same way), the process does not receive the SIGINT when I send it.
SIGTERM (default kill) works normally and closes the process, but does not let the process close gracefully, but I need.
What's happening?
process kill signals sigint
asked Dec 3 at 8:08
Eric
1062
add a comment |
up vote
1
down vote
favorite
I am on Ubuntu 16.04.5 LTS (AWS)
I am creating a python process via this command:nohup python -u main.py > nohup.out 2>&1 &
I would like to send a ctrl-c/SIGINT to the process, so I send kill -2 <pid>.
When I start the process from my terminal, this works fine, the program receives the keyboard interrupt and closes gracefully.
When I start the process via a .sh script or via another bash process (e.g. bash -c 'nohup python -u main.py > nohup.out 2>&1 &'). (I believe both methods start the process in the same way), the process does not receive the SIGINT when I send it.
SIGTERM (default kill) works normally and closes the process, but does not let the process close gracefully, but I need.
What's happening?
process kill signals sigint
asked Dec 3 at 8:08
Eric
1062
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I am on Ubuntu 16.04.5 LTS (AWS)
I am creating a python process via this command:nohup python -u main.py > nohup.out 2>&1 &
I would like to send a ctrl-c/SIGINT to the process, so I send kill -2 <pid>.
When I start the process from my terminal, this works fine, the program receives the keyboard interrupt and closes gracefully.
When I start the process via a .sh script or via another bash process (e.g. bash -c 'nohup python -u main.py > nohup.out 2>&1 &'). (I believe both methods start the process in the same way), the process does not receive the SIGINT when I send it.
SIGTERM (default kill) works normally and closes the process, but does not let the process close gracefully, but I need.
What's happening?
process kill signals sigint
asked Dec 3 at 8:08
Eric
1062
I am on Ubuntu 16.04.5 LTS (AWS)
I am creating a python process via this command:nohup python -u main.py > nohup.out 2>&1 &
I would like to send a ctrl-c/SIGINT to the process, so I send kill -2 <pid>.
When I start the process from my terminal, this works fine, the program receives the keyboard interrupt and closes gracefully.
When I start the process via a .sh script or via another bash process (e.g. bash -c 'nohup python -u main.py > nohup.out 2>&1 &'). (I believe both methods start the process in the same way), the process does not receive the SIGINT when I send it.
SIGTERM (default kill) works normally and closes the process, but does not let the process close gracefully, but I need.
What's happening?
process kill signals sigint
process kill signals sigint
asked Dec 3 at 8:08
Eric
1062
asked Dec 3 at 8:08
Eric
1062
edited Dec 3 at 8:13
asked Dec 3 at 8:08
Eric
1062
asked Dec 3 at 8:08
Eric
1062
asked Dec 3 at 8:08
Eric
1062
1062
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
No, they're not started in the same way. Since bash is running scripts with the job control turned off, the background mode of the commands started with & from a script is just "faked" by letting them ignore SIGINT and SIGQUIT and redirecting their input from /dev/null.
See my answer here (with references to the standard describing this).
In your case this also means the main.py isn't setting any handler for SIGINT in order to do a "graceful" exit, but it's just forcefully killed by a Control-C or kill -2 when run from an interactive shell. If it did set a handler, that handler would've also overridden the SIG_IGN disposition of SIGINT set by the parent shell when run from a script.
answered Dec 3 at 8:32
mosvy
5,2341323
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
No, they're not started in the same way. Since bash is running scripts with the job control turned off, the background mode of the commands started with & from a script is just "faked" by letting them ignore SIGINT and SIGQUIT and redirecting their input from /dev/null.
See my answer here (with references to the standard describing this).
In your case this also means the main.py isn't setting any handler for SIGINT in order to do a "graceful" exit, but it's just forcefully killed by a Control-C or kill -2 when run from an interactive shell. If it did set a handler, that handler would've also overridden the SIG_IGN disposition of SIGINT set by the parent shell when run from a script.
answered Dec 3 at 8:32
mosvy
5,2341323
add a comment |
up vote
1
down vote
No, they're not started in the same way. Since bash is running scripts with the job control turned off, the background mode of the commands started with & from a script is just "faked" by letting them ignore SIGINT and SIGQUIT and redirecting their input from /dev/null.
See my answer here (with references to the standard describing this).
In your case this also means the main.py isn't setting any handler for SIGINT in order to do a "graceful" exit, but it's just forcefully killed by a Control-C or kill -2 when run from an interactive shell. If it did set a handler, that handler would've also overridden the SIG_IGN disposition of SIGINT set by the parent shell when run from a script.
answered Dec 3 at 8:32
mosvy
5,2341323
add a comment |
up vote
1
down vote
up vote
1
down vote
No, they're not started in the same way. Since bash is running scripts with the job control turned off, the background mode of the commands started with & from a script is just "faked" by letting them ignore SIGINT and SIGQUIT and redirecting their input from /dev/null.
See my answer here (with references to the standard describing this).
In your case this also means the main.py isn't setting any handler for SIGINT in order to do a "graceful" exit, but it's just forcefully killed by a Control-C or kill -2 when run from an interactive shell. If it did set a handler, that handler would've also overridden the SIG_IGN disposition of SIGINT set by the parent shell when run from a script.
answered Dec 3 at 8:32
mosvy
5,2341323
No, they're not started in the same way. Since bash is running scripts with the job control turned off, the background mode of the commands started with & from a script is just "faked" by letting them ignore SIGINT and SIGQUIT and redirecting their input from /dev/null.
See my answer here (with references to the standard describing this).
In your case this also means the main.py isn't setting any handler for SIGINT in order to do a "graceful" exit, but it's just forcefully killed by a Control-C or kill -2 when run from an interactive shell. If it did set a handler, that handler would've also overridden the SIG_IGN disposition of SIGINT set by the parent shell when run from a script.
answered Dec 3 at 8:32
mosvy
5,2341323
edited Dec 3 at 8:39
answered Dec 3 at 8:32
mosvy
5,2341323
answered Dec 3 at 8:32
mosvy
5,2341323
answered Dec 3 at 8:32
mosvy
5,2341323
5,2341323
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f485630%2fprocess-started-by-script-does-not-receive-sigint%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
