Messages in this thread | | | Date | Fri, 19 Aug 2005 13:11:17 -0400 (EDT) | From | Elliot Lee <> | Subject | Re: [PATCH 2.6.13-rc6 1/2] New Syscall: get rlimits of any process (update) |
| |
On Thu, 18 Aug 2005, Alan Cox wrote:
> > Also some documention for specific services show that there is a need to > > adjust rlimits per process at runtime, e.g.: > > http://www.squid-cache.org/Doc/FAQ/FAQ-11.html#ss11.4 > > http://slacksite.com/apache/logging.html > > http://staff.in2.hr/denis/oracle/10g1install_fedora3_en.html#n2 > > Perhaps those application authors should provide a management interface > to do so within the soft limit range at least. Its not clear to me that > growing the fd array on a process is even safe. Some programs do size > arrays at startup after querying the rlimit data.
This is getting hung up on one particular example, while missing the bigger picture.
Being able to set rlimits for other processes is useful in general, just as things like nice() and sched_setscheduler() are. Maybe it is reducing max RSS on certain processes and increasing it on other processes, so that the memory tends to be used for higher-priority processes. Maybe it is setting max cpu time to T+5 minutes, so that if a seemingly stuck process has not exited in five minutes, it will die. Maybe it is limiting the number of processes that a daemon can spawn.
In addition, it's not always practical to have application authors provide a management interface.
You're right that there can be potential problems with adjusting rlimits on the fly, but that doesn't seem like a sufficient reason to avoid including the feature.
Best, -- Elliot Pioneers get the Arrows. Settlers get the Land. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |