On Mon, 9 Oct 2000 lamont@icopyright.com wrote:
> how about registering the full path (or inode number of the executable?),
> the owner, and an optional high water mark of memory consumption, over
> which the process is considered to be leaking memory and gets added to the
> algorithm of processes to kill? this is because while normally i want to
> ignore syslogd, if syslogd is consuming >20MB then it probably has sprung
> a leak.
Now we're getting somewhere! :)
Inode number would have to store disk maj:min too, and have the ability to
flush inodes stored for a particular disk when mounted/umounted. This might
cause a problem for one-time writes to a /proc entry that aren't refreshed when
the fs is [re]mounted.
Also, if you upgrade 'named' and replace the old executable, that inode entry
in /proc no longer makes sense. It's almost too hard to maintain by storing
the inode, unfortunately.
I like the idea for adding a high MB mark at which to kill the process (only
when OOM is kicked in). That can be added in addition to a priority scheme.
I envision a /proc format such as this, one entry per line:
/full/path/to/executable [priority] [max kbytes used]
where Priority is -20 to +20 (default 0), -20 being kill at last resort and +20
being try to kill these processes first.
max kbytes, if present and nonzero, would match this process only if its total
VSZ is >= kb.
An example file could be:
/sbin/init -20
/usr/sbin/syslogd -19
/usr/sbin/named -18
/usr/local/apache/bin/httpd -15
/usr/lib/netscape/netscape +15
/home/byron/daemonprogram -5 32768
Under the rule I described (below), /sbin/init is practically invalid because
adding that entry to the /proc file would come AFTER /sbin/init was first
executed.
httpd would be killed with greater priority than named and syslogd (assuming
VSZ was the same), in case of a memory leak. Of course, you might not want
this, and you can easily change it.
On the other hand, if my daemonprogram starts taking up more than 32 meg, then
kill it first before killing the other daemons (only when system is running low
on memory).
> it also might be good to have options to kill anything connected to a pty
> first, and to not kill anything attatched to the console. obviously these
> leave ways for admins to shoot themselves in the foot, but they could be
> useful.
I _had_ thought of that, but I don't know how clear that is in the process
structure. Malicious users can simply run setsid() to detach from a controlling
tty, thereby defeating the rule.
> also ignoring or including based on users and groups would be good (kill
> all the student logins, keep all the operator logins, or whatever...).
This would almost be in the same category as the 32-bit UIDs, where there are
TONS of people using a server or network cluster where memory shortage might
actually be a problem. I think it is a good route to explore.
> in general i like the idea of tunable OOM killing, since no one OOM killer
> suits everyone.
Agreed.
> > > What about a user-defined list of "wishes"? The administrator should be
> > > enabled to enforce that specific processes are to be terminated only as a
> > > last resource (syslogd), or that they should be killed first (netscape).
> > > Could that be done using some /proc interface - some lines, each
> > > containing a program name, and a modifier for the killing priority?
> >
> > echo "init" > /proc/sys/oom-ignore
> > echo "httpd" >> /proc/sys/oom-ignore
> > echo "parallel-fft" >> /proc/sys/oom-ignore
> > etc...
> >
> > This is a very workable option. It allows the admin to define what is
> > "important" on his computer and tells the OOM killer to terminate at
> > last resort (or ignore completely).
> >
> > I like it. Rik, what do you think?
>
> On Mon, 9 Oct 2000, Matthew Dharm wrote:
>
> > On Mon, Oct 09, 2000 at 09:25:38PM -0400, Byron Stanoszek wrote:
> > > echo "init" > /proc/sys/oom-ignore
> > > echo "httpd" >> /proc/sys/oom-ignore
> > > echo "parallel-fft" >> /proc/sys/oom-ignore
> > > etc...
> >
> > I'd be concerned with the security implications of this feature... after
> > all, I can edit argv[0] to change the name of my program -- a malicious
> > application could do this to attempt to "hide" from the OOM Killer.
>
> You have a point. How about specifying the complete path in the /proc file,
> so that a special bit is set on the process when it is executed.
>
> echo "/sbin/init" > /proc/sys/oom-ignore
>
> User does an execvp("init", ...)
>
> At this time, the user's path is searched for a match for "init".
> The kernel determines "/sbin/init" is the correct path name and begins
> to execute the program. It creates the process structure.
>
> Then, before starting program execution, it compares the full path with the
> list of entries in the /proc file. Seeing a match, it sets a bit (or a
> variable kill-rate) on the process structure. OOM reads this process structure
> in at kill-time and instantly determines which it should kill quickly or stay
> away from. If none apply, default to standard algorithm.
-- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: bstanoszek@comtime.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:14 EST