We Keep Coding

Keyboard interrupt bash and python script running in parallel

I have to execute two operations at the same time, one through a bash script and another through a python script. The simplest way to do it that I've found so far is to create a parent bash script to execute the two in parallel, such as this:
#!/bin/bash
bash process1.sh &
python3 process2.py &
I want to be able to interrupt the two processes at the same time using keyboard interrupt Ctrl+C. I tried adding
trap 'kill %1; kill %2' SIGINT
but the python script does not close as I'd like. In the python script there is a loop that should stop after the keyboard interrupt and perform some more operations after that, something like this
try:
# do something
except KeyboardInterrupt:
# Keyboard interrupt (Ctrl + C) detected
pass
# then do some final operations
but using kill does not propagate the keyboard interrupt to the python script, it just terminates the program as it is.
Is there a way to not kill the child python script, but to propagate the SIGINT to it?

Try this:
trap 'kill -INT %1 %2' INT

kill %2 sends SIGTERM (the default signal) to the Python process, not SIGINT. You want kill -INT inside the trap code.

Python- executing code lines after host force closing [duplicate]

I have a python 3 script and it runs on boot. And it work with some resources I want it free on exit.
How can I manage that script is going to exit if I'm killing it with kill -6 $PID.
Or any other ideas about how to send exit command and detect it in script.

The signal module is what you are looking for.
import signal
def handler(signum, frame):
print('Signal handler called with signal', signum)
signal.signal(signal.SIGABRT, handler)
Within the handler function you could terminate with sys.exit().
However, it is more common to use SIGINT (that's what happens when you press CTRL+C in the terminal) or SIGTERM to terminate a program. If you don't have cleanup code you don't need to write a single line of code to handle SIGINT - by default it raises a KeyboardInterrupt exception which, if not caught (that's a reason why you should never use blank except: statements), causes your program to terminate.

Python VS Code Debug - Capture SIGTERM?

I'd like to force sys.exit() when the python debugger is stopped. When I stop the debugger I see Terminated: 15 so I assume this is SIGTERM. However, when stopping the debugger, my kill function isn't called.
def kill(sig, frame):
sys.exit(0)
signal.signal(signal.SIGINT, kill)
signal.signal(signal.SIGTERM, kill)
When stopping the vscode debugger, what signal is sent?
Edit:
Just tried all of them. No love
for s in signal.Signals:
try:
signal.signal(s, self._kill)
except:
pass

For now we seem to be OOL (out of luck) - I ran into the same issue and found that VS Code python extension does issue a SIGKILL on debug stop, which cannot be cought.
Unlike the node.js extenstion, the Python extension also does not support setting the type to SIGTERM or SIGINT.
The only workaround I found is to have an open terminal (type: Pythen Debug Terminal) in VS Code. It should show the python command behavior and output during debug. Bring the terminal into focus by clicking on it and press ctrl-C manually. This should stop the debugged program gracefully and your catching the SIGTERM or SIGINT will work.

Execute a shell script with ampersand from a python program

I want to submit my long running Python job using ampersand. I'm going to kick this process off from an interactive Python program by using a sub process call it.
How would I keep track of the submitted job programmatically in case I want to end the job from a menu option?
Example of interactive program:
Main Menu
1. Submit long running job &
2. End long running job

If you're using python's subprocess module, you don't really need to background it again with & do you? You can just keep your Popen object around to track the job, and it will run while the other python process continues.
If your "outer" python process is going to terminate what sort of track do you need to keep? Would pgrep/pkill be suitable? Alternately, you could have the long running job log its PID, often under /var/run somewhere, and use that to track if the process is still alive and/or signal it.

You could use Unix signals. Here we capture SIGUSR1 to tell the process to communicate some info to STDOUT.
#!/usr/bin/env python
import signal
import sys
def signal_handler(signal, frame):
print('Caught SIGUSR1!')
print("Current job status is " + get_job_status())
signal.signal(signal.SIGUSR1, signal_handler)
and then from the shell
kill <pid> --signal SIGUSR1

Python signal.signal is it preventing propagation?

So I have this code (partially taken from python docs):
import signal
def handler(signum, frame):
print 'Signal handler called with signal', signum
s = signal.signal(signal.SIGINT, handler)
some_fancy_code() # this code is using subprocess.Popen() to call another script
singal.signal(signal.SIGINT, s)
What I found right now is that if I do Ctrl+C in my program, it correctly enters that handler and prints. Now, what I thought is that after receiving Ctrl+C my handler will suppress default handler so for example my subprocess.Popen will not get the KeyboardInterrupt signal. But this is not the case.
But when we replace 'handler' with 'signal.SIG_IGN', this propagation never happens. Modified snippet:
import signal
s = signal.signal(signal.SIGINT, signal.SIG_IGN)
some_fancy_code() # this code is using subprocess.Popen() to call another script
singal.signal(signal.SIGINT, s)
Is this because SIG_IGN is some kind of 'magic' signal written in language itself? Or maybe there is a way to make similar suppression in my own handler?
After reading a bit of question on stack overflow I am bit confused. If someone could make clear for me why such difference in behaviour.

This is the specified POSIX behaviour of signals:
A child created via fork(2) inherits a copy of its parent's signal dis‐
positions. During an execve(2), the dispositions of handled signals
are reset to the default; the dispositions of ignored signals are left
unchanged.
When you execute (fork/execve) your another script in the first case, the SIGINT handler is reset to the default handler in the another script (default behaviour is to terminate the process) - of course, the another script could install its own handler and change this behaviour.
However, in the second case, you've configured SIGINT to be ignored. This behaviour will be propagated to the another script, as indicated in the definition above. Again, the another script could change this behaviour by installing its own handler.
So this has nothing to do with Python directly. It is the expected behaviour of the underlying operating system's POSIX signal handling implementation.
PS. If you're wondering what fork() and execve() are, fork() creates a copy of the running process (a child) and execve() replaces the current process with another. This is the underlying mechanism used by subprocess.Popen() to run the 'another script': first make a copy of the current process and then replace it with the target process.