Bug #204

Better oom-survival overall

Added by Dave Täht almost 2 years ago. Updated about 1 year ago.

Status:In Progress Start date:07/10/2011
Priority:High Due date:
Assignee:Dave Täht % Done:

0%
Category:- Spent time: 3.50 hours
Target version:Cerowrt-Someday

Description

while I have patched xinetd to run with oom=1000, when it forks it cannot seem to reset the oom value of the forked process back to a sane value. (I have not folded this patch into the build yet, because of this)

Secondly, once that actually works, oom-protecting - or not - more stuff would be desirable.

Dropbear could run out of xinetd for sure... rsync already runs out of xinetd, netperf does also but some tests fail on the svn version.

Perhaps git-daemon...

Definately some sensors...

It would be great of lighttpd could run out of xinetd - or some web server - as you only need the web server running rarely... iperf -s doesn't work out of xinetd either....

nearly every daemon could run out of something like xinetd (I'm not sold on xinetd, or init, but
leaving processes around, unmonitored, is a sure recipe for eventual failure) Monit maybe. systemd and launchd are way too big and overdesigned for this task.

History

#1
Updated by Jim Gettys almost 2 years ago

Off the wall idea: I wonder what size Lennart Poettering's systemd is? It's like inetd on steroids, and applicable to things other than network services....

#2
Updated by Dave Täht almost 2 years ago

I looked at both systemd and launchd, shuddered, and moved on. I'm not letting lennart's design philosophy anywhere near an embedded platform.

that said I have half a patch for xinetd to better control the oom-killer, but for some reason it couldn't set child processes to anything other than 0 or 1000. I liked very much that it could set itself to 1000, however, and I thought about putting it in regardless of the problems.

if anybody wants to play with it, I'll upload it here.

#3
Updated by Dave Täht almost 2 years ago

  • Status changed from New to In Progress
  • Assignee set to Dave Täht
  • Priority changed from Normal to Urgent
  • Target version set to 1st Public Cerowrt release

#4
Updated by Dave Täht almost 2 years ago

Part 1 of this - getting xinetd to run with the oom killer disabled... is done.

Part 2 is to get more stuff into inetd.

#5
Updated by Dave Täht almost 2 years ago

  • Status changed from In Progress to Closed

root@sinope:/proc# ps | grep xinetd
3078 root 1208 S xinetd
3675 root 1640 S grep xinetd
root@sinope:/proc# cd 3078/
root@sinope:/proc/3078# ls
auxv exe mem oom_adj stat
cmdline fd mountinfo oom_score statm
comm fdinfo mounts oom_score_adj status
cwd limits mountstats personality task
environ maps net root wchan
root@sinope:/proc/3078# cat oom_score_adj
-1000

#6
Updated by Dave Täht almost 2 years ago

  • Status changed from Closed to In Progress

Actually, the fix I put in place makes the parent process -1000, which is what we want.

But no matter what I try, it also makes all the child processes -1000.

Ripped patch out of build.

#7
Updated by Dave Täht over 1 year ago

  • Priority changed from Urgent to High
  • Target version changed from 1st Public Cerowrt release to 13

as much as I would like to address this in the 1.0 it needs to be thunk through carefully and harmonized with stuff run out of init.

#8
Updated by Dave Täht about 1 year ago

  • Target version changed from 13 to Cerowrt-Someday

Also available in: Atom PDF