Bug#487325: openssh-server: /etc/default/ssh setting for oom_adj confused
tags 487325 pending thanks On Fri, Jun 20, 2008 at 07:27:30PM -0400, Micah Anderson wrote: I discovered recently during a testing migration that in a vserver environment you do not have the capability to adjust /proc values. This means that the oom_adj results in a lot of noise in the logfiles: sshd[9363]: error writing /proc/self/oom_adj: Operation not permitted I wonder if there's any way to detect this? Maybe I should just not print EPERM errors? If possible, I'd rather have a default that works for nearly everyone. Ok, so I thought I would disable it by tweaking the following in /etc/default/ssh: # OOM-killer adjustment for sshd (see # linux/Documentation/filesystems/proc.txt; lower values reduce # likelihood # of being killed, -17 = disable) SSHD_OOM_ADJUST=-17 Hmmm... its already set to -17 and -17 is 'disable'? Why isn't it disabled then if its already set here to be disabled? I think perhaps the wording here is simply misleading. What disable means here is disable the OOM-killer, that is tell the kernel never to kill this process. I've changed the text as follows: # OOM-killer adjustment for sshd (see # linux/Documentation/filesystems/proc.txt; lower values reduce likelihood # of being killed, while -17 means the OOM-killer will ignore sshd; set to # the empty string to skip adjustment) The source made me think that setting it to 0 should disable it: + const char *oom_adj = getenv(SSHD_OOM_ADJUST); + if (!oom_adj) + return; I've tried setting this to 0, -17, no setting, and commenting it out of the file altogether, but it still is being attempted After trial-and-error it seems like it shouldn't be set to anything at all if it is supposed to be disabled. So, the environment variable SSHD_OOM_ADJUST needs to be non-existant to actually disable it. I don't understand why, unless there is some environment scrubbing going on? My intent was that the empty string would prevent fiddling with the OOM-killer, but that didn't work due to an implementation bug (the above should have been 'if (!oom_adj || !*oom_adj) return;'). I've fixed this in CVS. It doesn't help that in /etc/init.d/ssh, we find this: export SSHD_OOM_ADJUST=-17 right before the sourcing of the /etc/default/ssh file. So the only way to really disable this is to comment out both the line in /etc/init.d/ssh where the environment variable is set to -17 and the line in /etc/default/ssh where it is also set. No, even at present, 'unset SSHD_OOM_ADJUST' in /etc/default/ssh would do it without having to edit the init script. I'm guessing that you were going for it a disable value of 0+ do it, but it seems that is completely ignored, for whatever reason that is beyond me. I wasn't - 0+ still adjusts the OOM-killer, just in a different direction. (The range of valid values offered by the kernel is -17 to +15. Not my idea!) Thanks for your report, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487325: openssh-server: /etc/default/ssh setting for oom_adj confused
* Colin Watson [EMAIL PROTECTED] [2008-06-21 03:07-0400]: tags 487325 pending thanks On Fri, Jun 20, 2008 at 07:27:30PM -0400, Micah Anderson wrote: I discovered recently during a testing migration that in a vserver environment you do not have the capability to adjust /proc values. This means that the oom_adj results in a lot of noise in the logfiles: sshd[9363]: error writing /proc/self/oom_adj: Operation not permitted I wonder if there's any way to detect this? Maybe I should just not print EPERM errors? If possible, I'd rather have a default that works for nearly everyone. After some discussion with the Linux-Vserver folks, they found some interesting information I thought it worth adding. First EPERM is not the error that they expected, and that inside a vserver guest its really strict about what options you open it with, both O_CREAT and O_TRUNC are forbidden, and O_WRONLY lets you write 0\n to it. The Linux-Vserver folks found that they didn't experience the exact same problem I did, they could set SSHD_OOM_ADJUST=0 in /etc/default/ssh, without changing the initscript. If I did that, I would get an error. This lead us to look into what was different, and it turned out that I am running a 2.6.18 kernel on the host (its pretty normal to run an etch host with guests that could be lenny, sid, or even redhat), and they were running a newer kernel. In 2.6.20 linux upstream remo removed the unconditional capable(CAP_SYS_RESOURCE) check. So that means that in kernels lower than 2.6.20 the capability CAP_SYS_RESOURCE is required to modify the oom_adj value at all. As capabilities are stripped in guests, unless you explicitly allow them, this is why I would get the error, and they wouldn't. With newer kernels, you just need the capability CAP_SYS_RESOURCE to lower the values. I think perhaps the wording here is simply misleading. What disable means here is disable the OOM-killer, that is tell the kernel never to kill this process. I've changed the text as follows: # OOM-killer adjustment for sshd (see # linux/Documentation/filesystems/proc.txt; lower values reduce likelihood # of being killed, while -17 means the OOM-killer will ignore sshd; set to # the empty string to skip adjustment) That clarifies the difference nicely! After trial-and-error it seems like it shouldn't be set to anything at all if it is supposed to be disabled. So, the environment variable SSHD_OOM_ADJUST needs to be non-existant to actually disable it. I don't understand why, unless there is some environment scrubbing going on? My intent was that the empty string would prevent fiddling with the OOM-killer, but that didn't work due to an implementation bug (the above should have been 'if (!oom_adj || !*oom_adj) return;'). I've fixed this in CVS. Great. It doesn't help that in /etc/init.d/ssh, we find this: export SSHD_OOM_ADJUST=-17 right before the sourcing of the /etc/default/ssh file. So the only way to really disable this is to comment out both the line in /etc/init.d/ssh where the environment variable is set to -17 and the line in /etc/default/ssh where it is also set. No, even at present, 'unset SSHD_OOM_ADJUST' in /etc/default/ssh would do it without having to edit the init script. Thats a better temporary solution, thanks for the suggestion. Thanks for your report, Thanks for the quick response, its appreciated, Micah signature.asc Description: Digital signature
Bug#487325: openssh-server: /etc/default/ssh setting for oom_adj confused
Package: openssh-server Version: 1:4.7p1-12 Severity: normal Hi there! I discovered recently during a testing migration that in a vserver environment you do not have the capability to adjust /proc values. This means that the oom_adj results in a lot of noise in the logfiles: sshd[9363]: error writing /proc/self/oom_adj: Operation not permitted Ok, so I thought I would disable it by tweaking the following in /etc/default/ssh: # OOM-killer adjustment for sshd (see # linux/Documentation/filesystems/proc.txt; lower values reduce # likelihood # of being killed, -17 = disable) SSHD_OOM_ADJUST=-17 Hmmm... its already set to -17 and -17 is 'disable'? Why isn't it disabled then if its already set here to be disabled? The source made me think that setting it to 0 should disable it: + const char *oom_adj = getenv(SSHD_OOM_ADJUST); + if (!oom_adj) + return; I've tried setting this to 0, -17, no setting, and commenting it out of the file altogether, but it still is being attempted After trial-and-error it seems like it shouldn't be set to anything at all if it is supposed to be disabled. So, the environment variable SSHD_OOM_ADJUST needs to be non-existant to actually disable it. I don't understand why, unless there is some environment scrubbing going on? It doesn't help that in /etc/init.d/ssh, we find this: export SSHD_OOM_ADJUST=-17 right before the sourcing of the /etc/default/ssh file. So the only way to really disable this is to comment out both the line in /etc/init.d/ssh where the environment variable is set to -17 and the line in /etc/default/ssh where it is also set. I'm guessing that you were going for it a disable value of 0+ do it, but it seems that is completely ignored, for whatever reason that is beyond me. In any case, having to edit the initscript to disable this is not the right way. I appreciate your continued maintainence of this package! Micah -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages openssh-server depends on: ii adduser 3.108 add and remove users and groups ii debconf [debconf-2.0] 1.5.22 Debian configuration management sy ii dpkg 1.14.19package maintenance system for Deb ii libc6 2.7-12 GNU C Library: Shared libraries ii libcomerr21.40.11-1 common error description library ii libkrb53 1.6.dfsg.4~beta1-2 MIT Kerberos runtime libraries ii libpam-modules0.99.7.1-6 Pluggable Authentication Modules f ii libpam-runtime0.99.7.1-6 Runtime support for the PAM librar ii libpam0g 0.99.7.1-6 Pluggable Authentication Modules l ii libselinux1 2.0.59-1 SELinux shared libraries ii libssl0.9.8 0.9.8g-10.1SSL shared libraries ii libwrap0 7.6.q-15 Wietse Venema's TCP wrappers libra ii lsb-base 3.2-12 Linux Standard Base 3.2 init scrip ii openssh-blacklist 0.4.1 list of default blacklisted OpenSS ii openssh-client1:4.7p1-12 secure shell client, an rlogin/rsh ii zlib1g1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages openssh-server recommends: ii openssh-blacklist-extra 0.4.1 list of non-default blacklisted Op ii xauth 1:1.0.3-2 X authentication utility -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
