"oom never" makes ssh upstart job fail to start in OpenVZ container
Bug #634900 reported by
Daniel Hahler
This bug affects 9 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
upstart (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
Binary package hint: upstart
/etc/init/ssh.conf uses "oom never", which causes the job failing to start in an OpenVZ container.
Host:
- kernel: 2.6.32-
Container:
openssh-server: 1:5.3p1-3ubuntu4 (Lucid)
Upstart: 0.6.5-7 (Lucid)
This is a known problem (mentioned on http://
What information is required to debug this? Some strace output?
WORKAROUND:
- comment the "oom never" line
POSSIBLE FIXES:
1. Ignore any errors when trying to set "oom never" for the job?!
2. Only apply "oom never" if not in a virtualized context (see comment #2).
description: | updated |
To post a comment you must log in.
I just updated my 10.04 LTS to 10.04.1 and fell into this trap. It is very annoying and I think the importance should be increased. The problem is that the original /etc/init.d/ssh included a test for virtual environments (searching for some string in /proc/self/status, it's gone after the update, of course) and prevented oom manipulation in these environments. It seems that this test has not found its way into upstart when handling the "oom" keyword.
In my case, I do not have any console access to the virtual environment. So I had absolutely no way of fixing this. Luckily, I had a very recent full backup and I could restore the system from the container management console.