Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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

share|improve this question
    
What OS is this? –  0xC0000022L Jun 12 at 21:26
    
it is ubuntu 64bits –  Aquarius Power Jun 12 at 21:45
2  
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 at 1: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 at 1: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 at 20:02

3 Answers 3

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...

share|improve this answer
    
thx! I set mine to 4194304 as also was suggested here, btw I found a way to count the wraps!! –  Aquarius Power Jun 13 at 0:30
    
@AquariusPower, please post the way you found as an answer. It will be informative for others too :) –  Ramesh Jun 13 at 0:33
    
it is imprecise but is precise enough! :) –  Aquarius Power Jun 13 at 0:39
    
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 at 0:48

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.

share|improve this answer
    
can be easily tested by replacing $! with $RANDOM –  Aquarius Power Jun 13 at 0: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 at 0: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 at 0:57

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).

share|improve this answer
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 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 at 0: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 at 2: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 at 2:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.