How to get pid of mpich processes - linux

I'm running my execuatable through mpirun command. I want to get the pid of processes being created so that I could kill them later if required. I'm using MPICH. In openmpi there is an option -report-pid which gives pids. Is there anything similar in MPICH?

Related

Is there a simple method to kill a process and all subprocess in linux system?

When I want to kill a process using the pid in linux, its subprocess still existes. I hope to kill all process using one command.
Suggesting command pkill -p PID pattern .
See more documentation here.
Check out process groups:
https://en.wikipedia.org/wiki/Process_group
Assuming you want to do this from a shell?
If you do a kill and make the top process negative it does a killpg under the covers and sends the signal to all the processes in the group.

Fetching pid and using it for kill

I have a batch file in linux (which I will execute externally from within my lazarus application). What it should do is read a process PID, store it in a variable, and use that variable to execute the "kill" command.
This is how I'm doing it:
PID=`pidof myProcess`
kill $PID
However, the kill command fails with a ": arguments must be process or job IDs" error.
How can I achieve this?
Perhaps using pkill directly would better suit your needs.
pkill myProcess
More info on pkill here: https://www.lifewire.com/list-and-kill-processes-using-the-pgrep-and-pkill-4065112

How to make killall close the terminal that the process is in?

So how can I close the terminal where the process is in with killall.
I have tried this:
In 1st terminal:
killall node
In 2nd terminal:
Ready
Terminated
But I want only the 2nd terminal to close after the node is killed.
You can use the -t option:
killall -t $(tty)
will call all processes started from the terminal session (even with nohup), including the shell. So, your terminal will get closed.
You need to also kill the process which runs the terminal, which is usually the parent process of the node process.
The question How do I get the parent process ID of a given child process? is a good place to start. You can find the PIDs of the node processes via How to find the Process ID of a running terminal program.

How to clear GPU memory occupied by zombie process if it's parent is init?

nvidia-smi screenshot
The process with PID 14420 is a zombie process and its parent id is 1(init). I want to clear 4436MiB memory occupied by this zombie process without rebooting.
How should I proceed?
Use this command to list all the processes on the GPU (on Linux).
sudo fuser -v /dev/nvidia*
and find PID from the listed processes and simply use
kill <PID> .
This will kill process with specified ID.

What happens to other processes when a Docker container's PID1 exits?

Consider the following, which runs sleep 60 in the background and then exits:
$ cat run.sh
sleep 60&
ps
echo Goodbye!!!
$ docker run --rm -v $(pwd)/run.sh:/run.sh ubuntu:16.04 bash /run.sh
PID TTY TIME CMD
1 ? 00:00:00 bash
5 ? 00:00:00 sleep
6 ? 00:00:00 ps
Goodbye!!!
This will start a Docker container, with bash as PID1. It then fork/execs a sleep process, and then bash exits. When the Docker container dies, the sleep process somehow dies too.
My question is: what is the mechanism by which the sleep process is killed? I tried trapping SIGTERM in a child process, and that appears to not get tripped. My presumption is that something (either Docker or the Linux kernel) is sending SIGKILL when shutting down the cgroup the container is using, but I've found no documentation anywhere clarifying this.
EDIT The closest I've come to an explanation is the following quote from baseimage-docker:
If your init process is your app, then it'll probably only shut down itself, not all the other processes in the container. The kernel will then forcefully kill those other processes, not giving them a chance to gracefully shut down, potentially resulting in file corruption, stale temporary files, etc. You really want to shut down all your processes gracefully.
So at least according to this, the implication is that when the container exits, the kernel will sending a SIGKILL to all remaining processes. But I'd still like clarity on how it decides to do that (i.e., is it a feature of cgroups?), and ideally a more authoritative source would be nice.
OK, I seem to have come up with some more solid evidence that this is, in fact, the Linux kernel doing the terminating. In the clone(2) man page, there's this useful section:
CLONE_NEWPID (since Linux 2.6.24)
The first process created in a new namespace (i.e., the process
created using the CLONE_NEWPID flag) has the PID 1, and is the
"init" process for the namespace. Children that are orphaned
within the namespace will be reparented to this process rather than
init(8). Unlike the traditional init process, the "init" process of a
PID namespace can terminate, and if it does, all of the processes in
the namespace are terminated.
Unfortunately this is still vague on how exactly the processes in the namespace are terminated, but perhaps that's because, unlike a normal process exit, no entry is left in the process table. Whatever the case is, it seems clear that:
The kernel itself is killing the other processes
They are not killed in a way that allows them any chance to do cleanup, making it (almost?) identical to a SIGKILL

Resources