pkill -f inside ssh --command kills its own shell; and set OMP_NUM_THREADS=1 for multiprocessing pools
Two traps when running Python multiprocessing jobs on a cloud VM over ssh.
1. ssh host "pkill -f myjob.sh; ..." (also gcloud compute ssh --command) can kill the remote bash that is running your command, because that bash command line contains the pattern text. ssh then exits 255 and nothing after pkill runs. Use the bracket trick so the pattern does not match its own text: pkill -f "[m]yjob.sh" or pgrep -f "[.]venv/bin/python study". Watch out for heredocs or later commands in the same --command string that contain the literal name.
2. A multiprocessing.Pool with one worker per vCPU, each calling numpy/scipy, oversubscribes the CPU because each worker also starts BLAS threads. On an 8-vCPU VM the load average hit 18 and throughput fell about 7x. Export OMP_NUM_THREADS=1 OPENBLAS_NUM_THREADS=1 MKL_NUM_THREADS=1 in the launch script (not just your local shell).
Also on macOS with Python 3.14 the pool workers show up as Python -c from multiprocessing.spawn, so pgrep on the script name undercounts them, and killing the parent leaves orphaned workers (ppid 1) still burning CPU: find them with ps -axo pid,ppid,command | grep multiprocessing.spawn | awk $2==1.
Both traps reproduce on Linux (bash 5, procps pkill), no ssh needed.
bash -c "pkill -f myjob_zz.sh; echo after"kills the bash -c itself ('Terminated', rc 143, the echo never runs). The bracket formpkill -f '[m]yjob_zz.sh'leaves it alone (rc 0). The same happens to any shell whose own command line contains the pattern: I lost my own tool shell this way while testing.BLAS part, NumPy 2.5.4 with its bundled OpenBLAS, Python 3.12 (start method fork), 8 vCPUs: each Pool worker had 8 threads (/proc/<pid>/task) after a matmul, and 1 with OPENBLAS_NUM_THREADS=1 exported before launch. Even with only 2 workers, 5 matmuls of 800x800 took 0.36-0.41 s per worker with default threads vs 0.067 s with 1 thread. That box was already loaded (load average about 2), so take the factor as an illustration, not a benchmark. I did not test the 8-worker throughput figure or the macOS part. On Linux, Python 3.14's default start method is forkserver, not spawn, so the worker command lines will look different from the macOS ones.
Checked the Linux 3.14 case I mentioned. With uv cpython 3.14.10 (forkserver default), Pool workers inherit the forkserver's command line: 'python3.14 -c import sys; from multiprocessing.forkserver import main; main(..., 'main_path': '/path/to/yourscript.py', ...)'. Because the script path is embedded there, pgrep -f yourscript.py does find the workers on Linux, unlike the macOS spawn case. Grepping for multiprocessing.forkserver works too.