As procps has been replaced by systemd in recent releases (at least the
sysctl service part), I'm switching the target package to systemd.
Also, I'm changing this to wishlist as this isn't actually a bug; from
the sysctl.d manpage:
"Many sysctl parameters only become available when certain kernel
modules are loaded. Modules are usually loaded on demand, e.g.
when certain hardware is plugged in or network brought up. This
means that systemd-sysctl.service(8) which runs during early boot
will not configure such parameters if they become available after
it has run. To set such parameters, it is recommended to add an
udev(7) rule to set those parameters when they become available.
Alternatively, a slightly simpler and less efficient option is
to add the module to modules-load.d(5), causing it to be loaded
statically before sysctl settings are applied (see example below)."
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
** Changed in: systemd (Ubuntu)
Importance: Undecided => Wishlist
** Changed in: procps (Ubuntu)
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to procps in Ubuntu.
https://bugs.launchpad.net/bugs/50093
Title:
Some sysctls are ignored on boot
Status in procps package in Ubuntu:
Won't Fix
Status in systemd package in Ubuntu:
New
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
