[Bug 50093] Re: Some sysctl's are ignored on boot

Andreas Ntaflos daff at dword.org
Wed Jan 18 14:57:47 UTC 2012


A possible workaround is putting "sysctl -p /etc/sysctl.conf" in
/etc/rc.local, which is ridiculous and doesn't even solve the problem
that networking and bridges are started *before* the sysctl settings are
applied.

It is even more ridiculous that this bug hasn't had any attention from
anyone except affected users in over five years. *Every* piece of
documentation regarding any kind of sysctl setting refers to
/etc/sysctl.conf as the place to put everything. And for over five years
there has been a really good chance that most of /etc/sysctl.conf gets
ignored because Ubuntu's boot process apparently doesn't know how when
and often to read and apply the settings in there. This isn't just an
upstart problem since upstart wasn't even around in 2006.

Bugs like this make it really difficult to recommend Ubuntu as a server
operating system and I wonder if Canonical really use Ubuntu as their
server OS. If they did it seems this bug would have been fixed years
ago.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/50093

Title:
  Some sysctl's are ignored on boot

Status in “procps” package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: procps

  /etc/init.d/procps.sh comes too early in the boot process to apply a
  lot of sysctl's. As it runs before networking modules are loaded and
  filesystems are mounted, there are quite a lot of commonly-used
  sysctl's which are simply ignored on boot and produce errors to the
  console.

  Simply renaming the symlink from S17 to > S40 probably isn't a great
  solution, as there are probably folk who want and expect some sysctl's
  to be applied before filesystems are mounted and so on. However,
  simply ugnoring something as important as sysctl settings isn't really
  on. Administrators expect the settings in /etc/sysctl.conf to take
  effect.

  One sto-gap solution would be to run sysctl -p twice; once at S17 and once at S41. There may still be some warnings and errors, but everything would be applied. A different, more complex approach might be to re-architect the sysctl configuration into something like;
   
      /etc/sysctl.d/$modulename

  and have the userland module-loading binaries take care of applying
  them after modules are loaded. Though this may take care of explicitly
  loaded modules only, I'm not sure.

  Incidentally, /etc/sysctl.conf still refers to
  /etc/networking/options, but hasn't that been deprecated?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/50093/+subscriptions




More information about the foundations-bugs mailing list