How to Get the Current Linux Process Id from the Command Line a in Shell-Agnostic, Language-Agnostic Way

How to get the current Linux process ID from the command line a in shell-agnostic, language-agnostic way

Great answers + comments here and here. Thx all. Combining both into one answer, providing two options with tradeoffs in POSIX-shell-required vs no-POSIX-shell-required contexts:

1. POSIX shell available: use $$
2. General cmdline: employ cut -d ' ' -f 4 /proc/self/stat

Example session with both methods (along with other proposed, non-working methods) shown here.

(Not sure how pertinent/useful it is to be so concerned with being shell independent, but have simply experienced many times the "run system call without shell" constraint that now seek shell-independent options whenever possible.)

Find pid of each process invoked within shell script

So for completeness, on the Python side, you can do:

import os, sys
print(os.getpid())
sys.stdout.flush()

to dump the current PID. You may want to print it to a file instead of the terminal so you can pick it up from that file.

In the shell, since you are just waiting for the cron job to run, another option is this (modified from this answer):

python foo.py & echo "$!" > "some file somewhere that will hold the PID" ; fg

That runs python foo.py in the background, saves the pid of the python process (which is in $! per this), and then returns python to the foreground so it can run normally.

Program to find from where the program is called

You can achieve it in python like this:

Basically it should be same, be it any programming language. You need to get the parent process ID and name of the process associated with it. If you use Java program, I guess you can achieve the same there also.

I named the python script as test.py and shell script as test.sh

test.py

import os
import psutil

ppid = os.getppid()
process_name = psutil.Process(ppid).name()

print("Parent process ID of current process is:", ppid)
print("The parent process name is: ", process_name)

test.sh

#!/bin/bash

python test.py

Output:

python test.py
('Parent process ID of current process is:', 14866)
('The parent process name is: ', 'bash')

./test.sh
('Parent process ID of current process is:', 15382)
('The parent process name is: ', 'test.sh')

standard way to communicate with a running process via shell script in linux

Since you also care about remote processes, and assuming you can modify the source code of all your programs, you could consider some way to communicate with them:

• defining your own small textual protocol, and have each process listening on some socket or some named pipe. You probably would need some multiplexing syscall like poll

• use existing libraries and tools like MPI, Corba, or perhaps D-Bus or ONC/RPC/XDR

• change the configuration files of your application, and have signal conventions, e.g. catch SIGHUP to reload the configuration, and SIGTERM to properly terminate it (but there is no way to send a signal remotely; you'll need e.g. to ssh some kill command).

Start a python script through a process and save the PID

You can use the subprocess package. Popen returns the instance process, you can save it, and later terminate it under certain condition. For example:

if [condition to init]:
  process = subprocess.Popen("./stuff someargs")

if [condition to stop]:
  process.kill()

You may use either kill or terminate, according to what you are trying to accomplish. Check the subprocess documentation for more details.

Start detached Unix process via fabric on multiple servers and retrieve status?

It seems that the preferred way would be to use screen or tmux.

http://www.fabfile.org/faq.html#why-can-t-i-run-programs-in-the-background-with-it-makes-fabric-hang

remote long running command

Figured out, just needed to use env.keepalive = 1

How do I write a bash script to restart a process if it dies?

Avoid PID-files, crons, or anything else that tries to evaluate processes that aren't their children.

There is a very good reason why in UNIX, you can ONLY wait on your children. Any method (ps parsing, pgrep, storing a PID, ...) that tries to work around that is flawed and has gaping holes in it. Just say no.

Instead you need the process that monitors your process to be the process' parent. What does this mean? It means only the process that starts your process can reliably wait for it to end. In bash, this is absolutely trivial.

until myserver; do
    echo "Server 'myserver' crashed with exit code $?.  Respawning.." >&2
    sleep 1
done

The above piece of bash code runs myserver in an until loop. The first line starts myserver and waits for it to end. When it ends, until checks its exit status. If the exit status is 0, it means it ended gracefully (which means you asked it to shut down somehow, and it did so successfully). In that case we don't want to restart it (we just asked it to shut down!). If the exit status is not 0, until will run the loop body, which emits an error message on STDERR and restarts the loop (back to line 1) after 1 second.

Why do we wait a second? Because if something's wrong with the startup sequence of myserver and it crashes immediately, you'll have a very intensive loop of constant restarting and crashing on your hands. The sleep 1 takes away the strain from that.

Now all you need to do is start this bash script (asynchronously, probably), and it will monitor myserver and restart it as necessary. If you want to start the monitor on boot (making the server "survive" reboots), you can schedule it in your user's cron(1) with an @reboot rule. Open your cron rules with crontab:

crontab -e

Then add a rule to start your monitor script:

@reboot /usr/local/bin/myservermonitor

---

Alternatively; look at inittab(5) and /etc/inittab. You can add a line in there to have myserver start at a certain init level and be respawned automatically.

---

Edit.

Let me add some information on why not to use PID files. While they are very popular; they are also very flawed and there's no reason why you wouldn't just do it the correct way.

Consider this:

1. PID recycling (killing the wrong process):

   • /etc/init.d/foo start: start foo, write foo's PID to /var/run/foo.pid
   • A while later: foo dies somehow.
   • A while later: any random process that starts (call it bar) takes a random PID, imagine it taking foo's old PID.
   • You notice foo's gone: /etc/init.d/foo/restart reads /var/run/foo.pid, checks to see if it's still alive, finds bar, thinks it's foo, kills it, starts a new foo.

2. PID files go stale. You need over-complicated (or should I say, non-trivial) logic to check whether the PID file is stale, and any such logic is again vulnerable to 1..

3. What if you don't even have write access or are in a read-only environment?

4. It's pointless overcomplication; see how simple my example above is. No need to complicate that, at all.

See also: Are PID-files still flawed when doing it 'right'?

By the way; even worse than PID files is parsing ps! Don't ever do this.

1. ps is very unportable. While you find it on almost every UNIX system; its arguments vary greatly if you want non-standard output. And standard output is ONLY for human consumption, not for scripted parsing!
2. Parsing ps leads to a LOT of false positives. Take the ps aux | grep PID example, and now imagine someone starting a process with a number somewhere as argument that happens to be the same as the PID you stared your daemon with! Imagine two people starting an X session and you grepping for X to kill yours. It's just all kinds of bad.

If you don't want to manage the process yourself; there are some perfectly good systems out there that will act as monitor for your processes. Look into runit, for example.

---

Related Topics