how to determine how many times pid_max wrapped?

Question

Is it even possible to know that? may be some kind of tests are required to be performed in order to find that information?

My system, just after I login, seem to have already wrapped the max_pid, so a still alive pid got the same pid of an old process (what messes one of mine scripts...)! I am trying to understand what is happening and if there is some workaround to that...

my /proc/sys/kernel/pid_max is 32768

If your actual question is "I created a process. How can I get notified that it has exited so I can avoid interacting with another process that comes along and happens to have the same pid", that would be interesting to ask. I think it's been asked before, but I can't find it at the moment. — Mark Plotnick, Jun 13 '14 at 01:33
@MarkPlotnick indeed you are right! or all pids are unique at least before each script interaction checking for the pids; or there is some safe way to workaround that! may be the pid full command string could be used as a secondary key to prevent the script accepting the new pid as being the old one! thx on the help, I will see what I can do later :) — Aquarius Power, Jun 13 '14 at 01:57
@MarkPlotnick but I really wanted to know how many wraps happened so that question remains, anyway I know now how to address the problems derived from it :) — Aquarius Power, Jun 13 '14 at 20:02

score 6 · Answer 1 · edited Apr 13 '17 at 12:37

It is not possible to tell how many times the pid_max wrap has occured. One work around to not encounter the pid_max wrapping is to increase the pid_max value inside,

cat /proc/sys/kernel/pid_max

The above command will let you know the maximum available processes in your system. You can increase the max_pid value as,

echo 4194303 > /proc/sys/kernel/pid_max

or even,

sysctl -w kernel.pid_max=4194303

However, you need to investigate if there are some processes that are currently utilizing the memory.

You can run either ps -A or ps -e to see what processes are currently utilizing your system's memory.

Why is it not possible to determine the wrap?

From this answer,

Most systems simply keep a count of the last PID generated, add one (wrapping at a maximum number such as 65535 or a bit smaller - often the wrap occurs at 65000 or even 60000), and check that the number is not currently in use (repeating if the PID is still in use - so PID 1, the kernel, is still there and doesn't get 'reissued').

Other security minded systems generate a number at random and check that it is not in use.

At any given time, it is guaranteed that all PID numbers are unique.

So even if pid_max is reached you still might have some pids that are currently not being used and so the system can still use those pids. As per as I know, the only time when you can know that you are out of pids is when you encounter an error as this comment says,

If you have processes > pid_max, you get error message like "No more processes...

thx! I set mine to 4194304 as also was suggested here, btw I found a way to count the wraps!! — Aquarius Power, Jun 13 '14 at 00:30
@AquariusPower, please post the way you found as an answer. It will be informative for others too :) — Ramesh, Jun 13 '14 at 00:33
at your answer, my script will only work if "simply keep a count of the last PID generated" is the case of the system.. — Aquarius Power, Jun 13 '14 at 00:48

score 1 · Answer 2 · edited Apr 13 '17 at 12:37

1

This code is possibly precise enough for most common situations:

#!/bin/bash
count=0;pidPrev=0;
while true;do
    echo -n & pidMax=$!;
    if((pidMax<pidPrev));then
        ((count++));
    fi;
    pidPrev=$pidMax;
    echo "$count,$pidMax";
    sleep 1;
done

Possible Flaws:
If pidMax is increased beyond pidPrev, it will fail.
If sleep delay is too high it may fail too.
It must be running when the machine is started and must not be stopped/restarted or count will loose its meaning.

Limitations:
This script worked here, on Ubuntu 14.04 64bits, but by Ramesh's answer you may find it wont work on your system, in case the assigned pid to a new process is random.

edited Apr 13 '17 at 12:37

Community

1

answered Jun 13 '14 at 00:38

Aquarius Power

4,289

can be easily tested by replacing $! with $RANDOM – Aquarius Power Jun 13 '14 at 00:42
Let's say during the first run pidMax is 8466 and this value will be assigned to pidPrev now. In the second iteration, if the pidMax is 9000 then, it will fail in the second iteration itself and it doesn't guarantee that the pid_max wrap is reached. – Ramesh Jun 13 '14 at 00:49
@Ramesh I saw that flaw too, that's why it has a possibility to be imprecise. But it is working very fine here! I have about 700 active pids at all time; my pids growth is about 1000 per second; being limited in 32768 was safe, now at 4194304 is great! unless the system generates random pids. This script could be improved to not work on such systems. At last the delay can be tweaked to cope with the growth :) – Aquarius Power Jun 13 '14 at 00:57

score 1 · Answer 3 · answered Jun 13 '14 at 02:25

1

Is there an xy problem that needs to be addressed here? In the question, it is mentioned

a still alive pid got the same pid of an old process (what messes one of mine scripts...)

How does it mess up the scripts? Is it because you're writing the PID of a process to a file, but later on it turns out that process has completed and now some other scripts are referencing the "wrong" PID?

Furthermore, all PID numbers are unique (see the quote in Ramesh's answer).

answered Jun 13 '14 at 02:25

h.j.k.

1,253

1

the pids are unique only for running processes, new process can have a pid of a died proccess; the script relies on a file that contains the pid information, but before such file being removed there is a delay of 10 minutes, meanwhile a new process got the same pid of a dead process and so the file was not removed; the tip by @MarkPlotnick made me think on adding the full command line to that file and so "pid vs cmd" would mostly be a unique enough combination, anyway I was able to create a script that count the wraps what is what I was interested in knowing :) – Aquarius Power Jun 13 '14 at 20:00
I know your script solves your original question to a certain extent, but as you have rightly pointed out under flaws and limitations, those make the applicability of your script very narrow and unsuitable as a generic, well-working answer. Especially the sleep 1 part, it just sounds hack-ish to me that a script will need to drift in and out of sleep every second just to check if pids have wrapped or not. Essentially, I'm agreeing with @MarkPlotnick that you should have a follow-up question asking how can you remove these PID files after the processes have stopped running... – h.j.k. Jun 14 '14 at 00:21
If my workaround about pids doesnt work I will think on a way to ask that question properly :). This question is mainly about counting wraps. I am still open to other solutions tho. My answer is "narrowed" (doesnt most ppl use ubuntu?) to ubuntu, but I would like to see another that could workaround random pids distribuition even if I cant test it. – Aquarius Power Jun 14 '14 at 02:37
The sleep 1 could be improved based on the "pids growth", so the faster, the lower would be the delay. I will code these stuff as soon I actually find a use for wraps counter other than "knowing it is somewhat cool" :) – Aquarius Power Jun 14 '14 at 02:41

how to determine how many times pid_max wrapped?

3 Answers3