# [Solved] Pid

## kosoul

What will be happen if process have last PID in system?Last edited by kosoul on Wed Mar 11, 2009 8:07 am; edited 1 time in total

----------

## pianosaurus

I don't know, but there are a whole lot of PIDs available. They are not strictly increasing either. I believe the kernel will fill in any holes, so you would have to try really hard to ever get there.

----------

## kosoul

Now i believe too:)

----------

## manaka

PIDs from previous processed are reused. You should only worry when surpassing the number of processes limit (/proc/sys/kernel/pid_max).

----------

## gentoo_ram

 *manaka wrote:*   

> PIDs from previous processed are reused. You should only worry when surpassing the number of processes limit (/proc/sys/kernel/pid_max).

 

Nah, pid_max doesn't really matter either.  That's just the pid value before the kernel will wrap around.  I guess it's a limit, but it's easy to change.  Not sure what /proc/sys/kernel/threads-max does.  Maybe that's some kind of limit?  But that can probably be bumped up as well.

----------

## mikegpitt

Doesn't a fork bomb fill all the processes in the system, causing it to basically lock?  I never actually tried to fork bomb a system, and don't want to start on my own   :Wink: 

Besides a blatant attack, I'd say you would have a hard time maxing out all pid's.

----------

## pianosaurus

 *mikegpitt wrote:*   

> Doesn't a fork bomb fill all the processes in the system, causing it to basically lock?

 

It is the process of creating new processes that consume all resources. This has traditionally become a problem long before the kernel runs out of PID space. I suspect that is still the case (even though parallel processing are evening the scores a bit). Like you though, I don't feel like testing it.

----------

## unkulunkulu

 *Cuber wrote:*   

> I don't feel like testing it.

 

After doing something like

```
sudo echo '@users hard nproc 500' >> /etc/security/limits.conf
```

you are safe.

----------

## pianosaurus

@unkulunkulu: True, but I believe the whole point here was to NOT limit the number of processes. I get your point, though.

----------

## timeBandit

The PID number just wraps around and the kernel starts reissuing available PIDs. There's no mystic requirement to have monotonically increasing PIDs, a PID is just a process identifier (literally). In normal use--fork bombs excluded--I imagine you'd arouse the ire of the OOM Killer or exhaust some other resource long before the kernel was unable to assign a PID for purely numeric reasons.

There is a kernel option (CONFIG_PID_NS, maybe?) to expand the PID range to 999,999 or some other big value ("cool factor!" says the help  :Smile: ). The only caution it carries is that some userland applications may not be prepared to handle large PIDs (think formatting errors, buffer overruns and such).

----------

## gentoo_ram

 *timeBandit wrote:*   

> 
> 
> There is a kernel option (CONFIG_PID_NS, maybe?) to expand the PID range to 999,999 or some other big value ("cool factor!" says the help ). The only caution it carries is that some userland applications may not be prepared to handle large PIDs (think formatting errors, buffer overruns and such).

 

It's easier than that:

# sysctl kernel.pid_max

32768

# sysctl kernel.pid_max=65536

You can put that value in /etc/sysctl.conf and it will be executed at system boot.  No kernel recompiles needed.

----------

## truc

 *unkulunkulu wrote:*   

>  *Cuber wrote:*   I don't feel like testing it. 
> 
> After doing something like
> 
> ```
> ...

 

You are not actually, since the redirection won't work (only the echo command is run as root)

You may do it like this(IIRC):

```
sudo bash -c "echo qsdfqdsf >> /etc/file"
```

 :Wink: 

----------

## RedSquirrel

 *truc wrote:*   

> You are not actually, since the redirection won't work (only the echo command is run as root)
> 
> You may do it like this(IIRC):
> 
> ```
> ...

 

Or you can use tee:

```
echo "asdfjkl" | sudo tee -a /etc/file
```

----------

## xbmodder

Ok, I just tried this. oom_killer will kick in if you run out of PIDs, and kick out PIDs (oom_kill them).

----------

## poly_poly-man

:(){ :|:& };:

and if you do run out of pids, you're doing it wrong. Use limits.conf to just get a nice warning when you do this, instead of a total lockup.

----------

## kosoul

That's true. I asked not for limit processes in system but what will be happen if I have process with max PID (for example 32768) and it make another process (not a lot of processes). Now I know that nothing big happen, but discussion is very interesting for me. I tried fork bomb on some system based on Red Hat kernel 2.4 and I can't did anything, but after 10 min everything come back to normal work. I tried it also on Windows XP SP2. One script used 50% processor power (one core), two scripts used 100% (2 cores), but work was still available. Conclusion: both systems have some mechanism, which make fork bomb not so bad for them.

----------

## kosoul

I think this discussion is solved, but how to change it to solved?

----------

## mikegpitt

 *kosoul wrote:*   

> I think this discussion is solved, but how to change it to solved?

 Click edit on the first post and change the title to the thread...

----------

