Re: setrlimit() extension suggestion

On Tue, 22 Apr 2008 08:16:42 -0700 (PDT) David Schwartz <davids@xxxxxxxxxxxxx> wrote:
| 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.

I did. It would be used as a _reliable_ means to ensure a process not be
run beyond a certain point in time.

I've since thought of different way to do it, which would be broader and
enable even more variety of uses. But some more details need to be worked
in the thought design. I'll post that idea if/when I work up those details.


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

You are making a judgement about a minute of time. The judgement should be
left up to whoever is making use of the facility. No one is required to use
it. And that's why the facility has a time setting. It is NOT a proposal
that specifies exactly one minute, no more no less.


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

There have been many times I've needed to limit runaway processes. This
is really an application issue and I do not believe it is appropriate for
discussion in this system oriented group.

I have been entrapped by requests like this before, where people then in turn
try to come up with many ways to do something similar, but is never the same
thing. Those suggestions also tend to be application specific and not a general
reusable solution. Even if I was willing to describe one application, I do not
want to keep repeating this over and over with each other application. So I
have limited what I propose to being a general purpose facility that can be
used by any number of applications that have a need for what it does.

If you can understand the effect as described by the suggestion, maybe you can
suggest a way to do it that does not involve a kernel change. I won't think
less of you if you cannot, because I cannot think of such a way.

If you cannot understand the effect as described, then I don't see any purpose
in continuing the discussion with you. But I highly doubt this is the issue.
I suspect it is more likely you do work more at the system level and less at
the application level and have simply never encounted the need because of the
lesser exposure. You and I frequently do not see things the same way, and
this might be at least one of the reasons why.

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

  • Re: setrlimit() extension suggestion
    ... The criteria for *removing* a feature are not the same as the criteria ... |> and kills the child. ... |> change process group). ... than 15 seconds wallclock time? ...
    (comp.os.linux.development.system)
  • Re: how to better handle links
    ... I am well on my way setting up a template. ... I do not know if html-kit has the replace ... would be feasible to use the replace feature. ... The point about the simplest "S & R over multiple docs" facility ...
    (alt.html)
  • Re: Questions on RDC over HTTP
    ... The general answer is no. :-) You can setup your own CA for this purpose. ... > that SSL is required for this feature. ...
    (microsoft.public.exchange.admin)
  • cut , copy, drag n drop and paste for an object
    ... once click copy button i need to store those ... information and for nother panel use, ... the main purpose for this feature is im trying to handle one ...
    (microsoft.public.dotnet.languages.vb)
  • Re: [PATCH 15/32] union-mount: Documentation
    ... dropped the patch by accident or on purpose, ... We will either put this feature back or fix the ... documentation. ...
    (Linux-Kernel)