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

Bug #634900 reported by Daniel Hahler on 2010-09-10
48
This bug affects 9 people
Affects Status Importance Assigned to Milestone
upstart (Ubuntu)
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-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).

Daniel Hahler (blueyed) wrote :
description: updated
tags: added: lucid
removed: apport-bug maverick
Changed in upstart (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
MNLipp (mnl) wrote :

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) wrote :

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

Daniel Hahler (blueyed) on 2011-02-19
description: updated
Salz` (salzig) wrote :

Same here with 10.04.02 in OpenVZ

Marcus Ilgner (milgner) wrote :

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) wrote :

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

Fabian (fsturm) wrote :

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) wrote :

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

Changed in upstart (Ubuntu):
importance: Medium → High
description: updated
James Lewis (james-fsck) wrote :

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) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers