"oom never" makes ssh upstart job fail to start in OpenVZ container

[Daniel Hahler]

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-5-openvz-amd64 (Debian testing)
Container:
openssh-server: 1:5.3p1-3ubuntu4 (Lucid)
Upstart: 0.6.5-7 (Lucid)

This is a known problem (mentioned on http://ubuntuforums.org/showpost.php?p=9170868&postcount=2).

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).

[MNLipp (mnl)]

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.

[Eric Kerby (erickerby)]

I can also confirm this in my updated 10.04.2 install which runs in an OpenVZ container on a CentOS host.

[Salz` (salzig)]

Same here with 10.04.02 in OpenVZ

[Marcus Ilgner (milgner)]

Same here. Luckily I was able to fix it using the Plesk filesystem browser and editing the file.
+1 for increasing importance.

[Patrik Karisch (patkar)]

Dito. Very annoying after the restart of my server in an OpenVz container, and i have to write the support.

[Fabian (fsturm)]

Hi,

yes I was bitten by it too. Just wasted 2 hours figuring it out via a plesk recovery console (strato).
Importance medium is a joke!! Often ssh is your only way to access a remote server, so a lot of people will get cur from their servers.

And no, I don't want to critique your wonderfull work, but sshd probles should be treated with highest priority.

Sincerely, Fabian

[Daniel Hahler (blueyed)]

> Importance medium is a joke
You will always be able to access the container from the host. Of course, this won't work easily if you do not have access to the host.
However, OpenVZ is not supported by Ubuntu and this is just one of the reasons why you would be better using Debian for server machines.
I am increasing the importance, but that does not make it more likely to get addressed in upstart unfortunately.

[James Lewis (james-fsck)]

Up until a few minutes ago, I had not found this bug, and had been starting sshd from the init.d script instead of upstart... but as of the last patch, the init.d script was modified to use upstart to start sshd, so I had to find the solution... commenting oom_never solved the problem, but now I need to identify why that is there in the first place.

[Xiaolin Zhang (zhangxiaolins)]

I ran into this problem today on 10.04.4 LTS, and the workaround works for me.

[Simon Déziel (sdeziel)]

I'll mark the bug as fix released as I think Ubuntu releases no longer suffer from this problem. Also, all Ubuntu releases still receiving normal support have moved away from upstart.