Re: setrlimit() extension suggestion

On Thu, 24 Apr 2008 10:46:27 +0200 Jacek Dziedzic <jacek.dziedzic__no--spam__@xxxxxxxxx> wrote:
| David Schwartz wrote:
| > [...]
|> I don't know. What's the actual problem? I understand that limiting
|> the wall clock time is your proposed solution, but solution TO WHAT?
|> Why don't you want it to run more than 15 seconds? (The solution to
|> your problem as stated is probably to write a trivial 'container'
|> program that launches a program in a new process group and kills that
|> process group in 15 seconds. But that might be the wrong solution to
|> your actual problem. I don't know.)
|
| How about: "There is an all-campus computer for the students to
| run their email and compile and run simple c++ programs. This is
| a small server machine, but there are hundreds of students using
| it. Some students test their MPI programs, when these deadlock,
| they leave tens of sleeping processes each. They do not utilize
| the CPU, but clutter outputs of 'top', 'ps' and the like with,
| in time, thousands of processes nobody needs. It would be good
| to automatically kill such deadlocked processes in, say, 4 hours
| rather than waiting for the next reboot."
|
| Admittedly, one could do that with a simple script.

These would generally be independent processes, and with no need for a means
to kill them off based on wallclock time. In their case, merely idleness
time might be appropriate. But the accuracy of the time is far from critical
here, and they can be killed off by the script in a somewhat reliable way.
This is not the kind of thing that inspired my suggestion.

Note that such a script would have a very slight exposure to killing the wrong
process. If it acquires a process ID of a process that has been present for
quite a long time doing nothing, then before it can kill that process, that
process exits just as the process ID roller reaches the same number, and a new
process is forked with the same PID, that new process gets killed.

The script might have a tough time of killing off a process that is forking
new instances of itself every few milliseconds, with the parent exiting as
each new child is created.

In the case of what I'm doing, the timelimit program basically does the job.
It just has certain reliability exposures that I do not trust. This is the
kind of thing I believe the kernel should be doing. But I am thinking about
a more flexible way to do so than the way I previously posted.

--
|WARNING: Due to extreme spam, I no longer see any articles originating from |
| Google Groups. If you want your postings to be seen by more readers |
| you will need to find a different place to post on Usenet. |
| Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |
.

Relevant Pages

  • How do I kill a runaway process which continue generating new processes
    ... A user runs a script which continues to generate new processes due to ... a bug. ... killing is not fast enough: ... I am wondering if there is a way to kill all his processes without ...
    (comp.unix.shell)
  • Re: How to kill a logged in user?
    ... > in your script. ... >> Anyone know what packages are on the rescue CD? ... How to kill a logged in user? ... Also on my TODO list is a mailing list export/import modul, from which we can convert mail threads into FAQs. ...
    (Fedora)
  • RE: How to kill a logged in user?
    ... How to kill a logged in user? ... information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station, ... > in your script. ... from which we can convert mail threads into FAQs. ...
    (Fedora)
  • Re: logon script for an examination account
    ... Oh, I should point out, Jason, I see that your script copies the ... pre-formatted word doc to the folder that's created. ... They also provide students with 50% of their final mark. ... The idea is that the students put the id# in the Word doc's footer rather ...
    (microsoft.public.scripting.vbscript)
  • Re: Privileges and killing a process
    ... >Hi Lee - ... sure seems like a lot of code when you can run a simple script ... then the application will kill them. ... >>>Dim hProcess As Long ...
    (microsoft.public.vb.general.discussion)