On Wed, Aug 22, 2007 at 09:40:37PM -0500, Matt Mackall wrote: > On Tue, Aug 21, 2007 at 11:56:11AM -0700, Andy Isaacson wrote: > > On Fri, Aug 17, 2007 at 12:45:47PM -0700, Andrew Morton wrote: > > > On Fri, 17 Aug 2007 06:59:18 -0400 > > > Neil Horman <[EMAIL PROTECTED]> wrote: > > > > Currently, there exists no method for a process to query the resource > > > > limits of another process. They can be inferred via some mechanisms > > > > but they cannot be explicitly determined. Given that this > > > > information can be usefull to know during the debugging of an > > > > application, I've written this patch which exports all of a > > > > processes limits via /proc/<pid>/limits. > > > > > > I'm struggling with this a bit. Sure, it _might_ be handy on some > > > occasions to be able to get at this information. But I've never seen > > > anyone ask for it before, and it _is_ determinable by other means, if only > > > strace. > > > > I've wanted this information on multiple occasions in the past and was > > mystified that there was no way to determine it. And no, I don't feel > > that strace is an answer -- given a running process, how do I use strace > > to find out what its current ulimits are? > > You stop it and force it to execute rlimit(2) in its context, of > course! What could be simpler? > I would think reading a file in /proc would be simpler :), especially if you're in a position where attaching to the process through ptrace isnt feasible. For instance, if you were an application running as the result of a core dump when /proc/sys/kernel/core_pattern were a pipe, preforming your operation wouldn't be particularly possible. Likewise, if your a sysadmin and you want to check what your processes limits were, you could follow your method, but I would think you would much rather avoid needing to send several ptrace commands to your commands, interrupting its work if you didn't have to.
> The reason we never see questions about this is because relatively few > people are using limits. Instead we see weekly questions about fork > bombs. > But we do see questions about this. I've had a few requests, and at least two more people have popped up on this thread supporting it. Regards Neil -- /*************************************************** *Neil Horman *Software Engineer *Red Hat, Inc. [EMAIL PROTECTED] *gpg keyid: 1024D / 0x92A74FA1 *http://pgp.mit.edu ***************************************************/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
