Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Process Table Flood?

Status
Not open for further replies.

SamBones

Programmer
Aug 8, 2002
3,186
US
What happened is, a user was writing a script and was trying to debug a problem with it. The script had a "sleep 1" in it, but the user wanted to increase the sleep time without altering the script. The user created another script called "sleep" in their home directory with one line in it, "sleep 30". They then made their home directory the first directory in their PATH so it would find their version of "sleep" instead of the system version. They then ran their main script.

If the one line in the "sleep" script had been "/usr/bin/sleep 30", then everything would have been fine. As it was written, with no path, it was just rerunning itself recursively. This cause the machine to lock up tighter than a drum. A few things kept running very slowly, but many things just froze and many things crashed. It was impossible to log in.

So, my question is, how is this possible? I was under the impression that process table flooding was a thing of the past due to limiting the number of processes per user or process tree or some other factor.

Also, how can this be prevented? Is there a system tuning parameter that can limit this kind of thing? This was a simple one line script run my a non-privileged user. This shouldn't be possible.

Just for background, this is a Solaris 10 system, fully patched and up-to-date.

 
I think maybe the v.v_maxup parameter in /etc/system is what you're looking for?

On my "untuned" Solaris 10 x86 VM these are the values shown by sysdef:

Code:
*
* Tunable Parameters
*
21295104        maximum memory allowed in buffer cache (bufhwm)
   16250        maximum number of processes (v.v_proc)
      99        maximum global priority in sys class (MAXCLSYSPRI)
   16245        maximum processes per user id (v.v_maxup)

So out of the box it doesn't give much headroom between global processes and those of an individual user.

Annihilannic
[small]tgmlify - code syntax highlighting for your tek-tips posts[/small]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top