[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2023-04-11 Thread Launchpad Bug Tracker
Status changed to 'Confirmed' because the bug affects multiple users.

** Changed in: systemd (Ubuntu)
   Status: New => Confirmed

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


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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2022-05-19 Thread fuckyouopensource
"sysctl.d docs clearly explain this is a known issue with clearly
documented ways to work around it"

Try googling "how to disable ipv6 in ubuntu". The results suggest that
the word "clearly" is misused.

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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2021-04-06 Thread Dan Streetman
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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2021-04-06 Thread Dan Streetman
Just to reiterate, I'm only marking procps as 'wontfix' because the
sysctl service used in all current releases comes from systemd, *not*
the procps package, so there is nothing to 'fix' in the procps package.

Also, before people get upset, I've only marked this as Wishlist because
the sysctl.d docs clearly explain this is a known issue with clearly
documented ways to work around it. That doesn't mean i don't think this
should be fixed; I absolutely do agree it should be fixed to properly
apply all sysctl settings at boot, including for loadable modules loaded
after boot. That will require upstream systemd work to implement,
however, before backporting into Ubuntu.

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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2021-04-06 Thread Drew Freiberger
Still seeing this in bionic 18.04.3 with the following kernel and procps
package.

ii  procps 2:3.3.12-3ubuntu1.2
amd64/proc file system utilities

kernel 5.4.0-62-generic

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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2020-10-24 Thread Rafael David Tinoco
** Changed in: procps (Ubuntu)
 Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)

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

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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2020-04-05 Thread Martin Streďanský
Still no fix? I have just ran into the same problem...

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

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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2019-06-07 Thread Rafael David Tinoco
I have added a file in /etc/sysctl.d/98-* setting up NFS sysctl
parameters and they were not loaded by default until I have added:

nfsd

to /etc/modules, re-generated the initramfs and rebooted, checking it
again, when it worked.

** Changed in: procps (Ubuntu)
 Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco)

** Changed in: procps (Ubuntu)
   Importance: Low => Medium

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

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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2019-02-21 Thread Радогор
I have the same problem in Debian 9 Stretch, net.netfilter.nf_conntrack_max and 
net.nf_conntrack_max does not apply after reboot. The pure solution is load 
module nf_conntrack before sysctl. You can do this with the command:
echo "nf_conntrack" >> /etc/modules

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

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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2019-02-14 Thread Zsolt Ero
Actually, the line which works without specifying a PATH in a cron.d
file is the following:

@reboot root /bin/sleep 5 && /sbin/sysctl --system

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

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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2019-02-14 Thread Zsolt Ero
I feel it's important to add that the very last comment (Stanley
Sisneros (stanley-sisneros) wrote on 2018-05-30) is wrong, and the right
workaround is by Tomasz Konefal (twkonefal-j) wrote on 2018-05-07.

That is, add this to crontab:
@reboot root sleep 5 && sysctl --system

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

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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2018-05-30 Thread Stanley Sisneros
In Ubuntu 16.04 I made this work by adding the following to crontab -e

@reboot sleep 15; /sbin/sysctl -p

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

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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2018-05-07 Thread Tomasz Konefal
A workaround for this that we're using now is to put the sysctl
processing into crontab after reboot.

e.g.
@reboot root sleep 5 && sysctl --system

Maybe one day someone will fix this bug :)

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

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


[Touch-packages] [Bug 50093] Re: Some sysctls are ignored on boot

2018-04-13 Thread Paul Gear
** Summary changed:

- Some sysctl's are ignored on boot
+ Some sysctls are ignored on boot

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

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