Re: [RFC] New ideas for the OOM handler
Long-running processes are not always important. If I'm running an RC5 cracker or similar program, I want that killed right after the fork bomb. While it's generally bad to interrupt simulations etc., it is perfectly fine to do so if they are properly designed so they save their state as they go along. If I were writing a really long simulation, I'd make sure it was interruptible, and that there were provisions for automatically restarting it when it died. Note: On long-running, unsupervised systems, it is sometimes better to reboot than to do an OOM kill, unless the system is set up to be able to automatically restart critical programs that die. For instance, if a mail server gets OOM because of a mem leak in sendmail, it's better to crash and reboot than to kill sendmail, unless it's auto-restarted. -- This message has been brought to you by the letter alpha and the number pi. David Feuer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] New ideas for the OOM handler
Long-running processes are not always important. If I'm running an RC5 cracker or similar program, I want that killed right after the fork bomb. While it's generally bad to interrupt simulations etc., it is perfectly fine to do so if they are properly designed so they save their state as they go along. If I were writing a really long simulation, I'd make sure it was interruptible, and that there were provisions for automatically restarting it when it died. Note: On long-running, unsupervised systems, it is sometimes better to reboot than to do an OOM kill, unless the system is set up to be able to automatically restart critical programs that die. For instance, if a mail server gets OOM because of a mem leak in sendmail, it's better to crash and reboot than to kill sendmail, unless it's auto-restarted. -- This message has been brought to you by the letter alpha and the number pi. David Feuer [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] New ideas for the OOM handler
On Mon, 9 Oct 2000, Byron Stanoszek wrote: > > 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. Well, I wasn't thinking about killing pty-attatched processes as being necessarily 100% effective or secure, but merely potentially useful. Clearly it doesn't help in the case of a malicious forkbombing user. Sparing console processes seems like it should be reasonably secure though (at least as secure as your console is). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] New ideas for the OOM handler
On Mon, 9 Oct 2000, Byron Stanoszek wrote: 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. Well, I wasn't thinking about killing pty-attatched processes as being necessarily 100% effective or secure, but merely potentially useful. Clearly it doesn't help in the case of a malicious forkbombing user. Sparing console processes seems like it should be reasonably secure though (at least as secure as your console is). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] New ideas for the OOM handler
On Mon, 9 Oct 2000 [EMAIL PROTECTED] 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
Re: [RFC] New ideas for the OOM handler
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. 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. also ignoring or including based on users and groups would be good (kill all the student logins, keep all the operator logins, or whatever...). in general i like the idea of tunable OOM killing, since no one OOM killer suits everyone. > > 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? > > > Just a thought. Hope my English is not too bad to make my thoughts > > clear... Sorry if this was discussed on l-k before - I do not have the > > time to read each posting on the list. > > > > > > Greetings from Germany, > > > > Jochen Striepe. > > > > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] New ideas for the OOM handler
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
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] New ideas for the OOM handler
On Mon, Oct 09, 2000 at 09:25:38PM -0400, Byron Stanoszek wrote: > On Tue, 10 Oct 2000, Jochen Striepe wrote: > > 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'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. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I want my GPFs!!! -- Stef User Friendly, 11/9/1998 PGP signature
Re: [RFC] New ideas for the OOM handler
On Tue, 10 Oct 2000, Jochen Striepe wrote: > Hi, a question regarding the OOM process killer... > > Hmm, sometimes daemon-like processes (e.g. web servers) only need root > privileges to open a network port<1024 - you may start them as non-root > if they do not need such a privileged port. Might be hard to sort them > out... That is very true. I run several daemons in non-superuser mode that would become the victim of that. This reminds me of an earlier post where I discussed that CPU Time should not be factored in. I may have misunderstood (my apologies to Rik). What is more important is how long the process has been running (daemons usually get started first thing at bootup, versus running 'netscape' and shortly using up all memory in 30 minutes). Figuring in Time Since Process Creation can almost be a misguided way of doing things. I don't know how many times I've restarted or upgraded 'named' on my 90-day-uptime system, just to change the configuration file or to back out invalid serial numbers in DNS zone files. However, if I have been running a 99% cpu-intensive mathematical modeling program for the past 10 days, I wouldn't want it to get killed because it allocated 50 MB in the first second of its life when the system had 250MB to spare. However, what if I started up netscape on day 1, ran tons of other processes meanwhile, and only used netscape lightly day by day. After 90 days of light usage, netscape might actually be using 150MB of ram now. Does netscape (rightfully) get killed, or does my modeling program which only uses 50MB get killed because I started it only 10 days ago instead of 90 days? Neither process start date nor CPU Usage % can correctly detect which process to kill over a period of 10 to 90 days, in this scenario. This is why I don't like factoring in these two elements. The OOM killer will get this right 90% of the time, maybe even 95%. But what about the sequential 'child worker' that was forked off of the modeling program once every 5 hours? I think there should be a better solution. > 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? > Just a thought. Hope my English is not too bad to make my thoughts > clear... Sorry if this was discussed on l-k before - I do not have the > time to read each posting on the list. > > > Greetings from Germany, > > Jochen Striepe. > > -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] New ideas for the OOM handler
On Tue, 10 Oct 2000, Jochen Striepe wrote: Hi, a question regarding the OOM process killer... Hmm, sometimes daemon-like processes (e.g. web servers) only need root privileges to open a network port1024 - you may start them as non-root if they do not need such a privileged port. Might be hard to sort them out... That is very true. I run several daemons in non-superuser mode that would become the victim of that. This reminds me of an earlier post where I discussed that CPU Time should not be factored in. I may have misunderstood (my apologies to Rik). What is more important is how long the process has been running (daemons usually get started first thing at bootup, versus running 'netscape' and shortly using up all memory in 30 minutes). Figuring in Time Since Process Creation can almost be a misguided way of doing things. I don't know how many times I've restarted or upgraded 'named' on my 90-day-uptime system, just to change the configuration file or to back out invalid serial numbers in DNS zone files. However, if I have been running a 99% cpu-intensive mathematical modeling program for the past 10 days, I wouldn't want it to get killed because it allocated 50 MB in the first second of its life when the system had 250MB to spare. However, what if I started up netscape on day 1, ran tons of other processes meanwhile, and only used netscape lightly day by day. After 90 days of light usage, netscape might actually be using 150MB of ram now. Does netscape (rightfully) get killed, or does my modeling program which only uses 50MB get killed because I started it only 10 days ago instead of 90 days? Neither process start date nor CPU Usage % can correctly detect which process to kill over a period of 10 to 90 days, in this scenario. This is why I don't like factoring in these two elements. The OOM killer will get this right 90% of the time, maybe even 95%. But what about the sequential 'child worker' that was forked off of the modeling program once every 5 hours? I think there should be a better solution. 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? Just a thought. Hope my English is not too bad to make my thoughts clear... Sorry if this was discussed on l-k before - I do not have the time to read each posting on the list. Greetings from Germany, Jochen Striepe. -- Byron Stanoszek Ph: (330) 644-3059 Systems Programmer Fax: (330) 644-8110 Commercial Timesharing Inc. Email: [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] New ideas for the OOM handler
On Mon, Oct 09, 2000 at 09:25:38PM -0400, Byron Stanoszek wrote: On Tue, 10 Oct 2000, Jochen Striepe wrote: 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'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. Matt -- Matthew Dharm Home: [EMAIL PROTECTED] Maintainer, Linux USB Mass Storage Driver I want my GPFs!!! -- Stef User Friendly, 11/9/1998 PGP signature
Re: [RFC] New ideas for the OOM handler
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
--
Byron Stanoszek Ph: (330) 644-3059
Systems Programmer Fax: (330) 644-8110
Commercial Timesharing Inc. Email: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] New ideas for the OOM handler
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. 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. also ignoring or including based on users and groups would be good (kill all the student logins, keep all the operator logins, or whatever...). in general i like the idea of tunable OOM killing, since no one OOM killer suits everyone. 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? Just a thought. Hope my English is not too bad to make my thoughts clear... Sorry if this was discussed on l-k before - I do not have the time to read each posting on the list. Greetings from Germany, Jochen Striepe. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] New ideas for the OOM handler
On Mon, 9 Oct 2000 [EMAIL PROTECTED] 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
