Re: setrlimit() extension suggestion

On Apr 21, 11:36 am, phil-news-nos...@xxxxxxxx wrote:
On Mon, 21 Apr 2008 04:58:53 -0700 (PDT) David Schwartz <dav...@xxxxxxxxxxxxx> wrote:
| On Apr 20, 10:43 pm, phil-news-nos...@xxxxxxxx wrote:

|> I'd like to suggest an extension to setrlimit() and getrlimit(). The resource
|> symbol would be RLIMIT_TIME (or RLIMIT_LINUX_TIME to designate an extension in
|> case a future POSIX change uses RLIMIT_TIME in an incompatible way). What it
|> should do is set a limit on "wallclock" time.
|
| I can't think of a use for it.

I'd like to suggest that all the features in Linux that you can't think of
a use for be immediately removed.

The criteria for *removing* a feature are not the same as the criteria
for *adding* a feature.

I had a use for it yesterday. I ended up using the "timelimit" program in
the netpipes package.

Well then explain the use! If you're going to suggest that a feature
be added, you should at least explain what it might be used for.

|> Unreliable means exist now. One of them is a parent process that keeps time
|> and kills the child. But a child could "run away" fairly easily (fork and
|> change process group). A hard RLIMIT_TIME would be inescapable.
|
| I don't see how that would be useful. You would face an insoluable
| "three bears" problem. Minutes are too low for long-lived working
| processes, but seconds are too long for fork bombs.

Uh ... you can specify whatever time limit you want. Minutes and seconds are
just a resolution. If 15 seconds is just right, then use that. If you think
we need a finer resolution than 1 second, what is in your mind? Milliseconds?

I guess you missed my point. You are advocating a new feature. You
claim it might be useful to prevent a child from running away. I'm
saying it couldn't be used for that purpose. If you set the limit to a
time measured in minutes, you can still allow the child to run away
for a minute, which is way too much. If you set the limit to a time
measured in seconds, you will damage long-running processes that don't
hurt the system at all.

| If that's the job, the proposed RLIMIT_TIME is the wrong tool.

What do you think is the right tool to make sure a process be run for no more
than 15 seconds wallclock time (it doesn't use much CPU time)?

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

DS
.

Relevant Pages

  • Re: setrlimit() extension suggestion
    ... | for *adding* a feature. ... |> |> change process group). ... And that's why the facility has a time setting. ... have limited what I propose to being a general purpose facility that can be ...
    (comp.os.linux.development.system)
  • Re: sleep/fork/shell/SIGCHLD interaction problem
    ... Then I found that is I press ctrl-Z to suspend the parent whilst I'm ... SIGCHLD is sent to the parent whenever a child changes status. ... you press ctrl-Z, the whole process group is signalled, the child is ... and free it does a good job of, but signals I guess are harder. ...
    (comp.lang.perl.misc)
  • Re: Killing sons (Linux)
    ... realized why - the PID I'm keeping is of the daemon fork. ... doesn't kill all of its sons - it causes bash to get reparented to init! ... add each child to the parent's process ... added to the same process group. ...
    (comp.lang.ruby)
  • Re: Sending Cntrl-C ??
    ... Make the child start a new process group, then its pid is the process group ID. ... print "send Ctrl-Break" ...
    (comp.lang.python)
  • Re: (Still Does Not Work) From Red Hat Linux, Perl system Creates Program That Dies When First C Pro
    ... >executing, so does the program started using nohup. ... The parent will waitfor the child to terminate. ... its process group will be sent a SIGHUP. ...
    (comp.os.linux.misc)