procps runs too early in the boot process
Bug #771372 reported by
Mark Russell
This bug affects 20 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
procps (Ubuntu) |
Fix Released
|
Medium
|
James Hunt | ||
Lucid |
Fix Released
|
Medium
|
James Hunt | ||
Maverick |
Won't Fix
|
Medium
|
James Hunt | ||
Natty |
Won't Fix
|
Medium
|
James Hunt | ||
Oneiric |
Won't Fix
|
Medium
|
Unassigned | ||
Precise |
Fix Released
|
Medium
|
James Hunt |
Bug Description
Binary package hint: upstart
The start on criteria is for procps.conf is:
start on virtual-filesystems
This runs before some kernel modules are loaded, and procps applies the settings before they "exist", this is most noticed with network and network-related jobs (nfs, bridge).
This bug may be considered a duplicate of LP Bug #690433. I am opening a new one anyway, however because I think it's worth considering a more robust solution that would work for any possible kernel module.
Related branches
lp:~jamesodhunt/ubuntu/precise/procps/fix-for-bug-771372
- Steve Langasek: Pending requested
- Ubuntu branches: Pending requested
-
Diff: 31 lines (+12/-1)2 files modifieddebian/changelog (+9/-0)
debian/upstart (+3/-1)
lp:~jamesodhunt/ubuntu/lucid/procps/fix-for-bug-771372
Ready for review
for merging
into
lp:ubuntu/lucid/procps
- Steve Langasek: Pending requested
-
Diff: 32 lines (+13/-1)2 files modifieddebian/changelog (+9/-0)
debian/upstart (+4/-1)
Changed in procps (Ubuntu Lucid): | |
status: | New → Triaged |
Changed in procps (Ubuntu Maverick): | |
status: | New → Triaged |
Changed in procps (Ubuntu Natty): | |
status: | New → Triaged |
Changed in procps (Ubuntu Oneiric): | |
status: | New → Triaged |
Changed in procps (Ubuntu Lucid): | |
importance: | Undecided → Medium |
Changed in procps (Ubuntu Maverick): | |
importance: | Undecided → Medium |
Changed in procps (Ubuntu Natty): | |
importance: | Undecided → Medium |
Changed in procps (Ubuntu Oneiric): | |
importance: | Undecided → Medium |
Changed in procps (Ubuntu Precise): | |
assignee: | nobody → James Hunt (jamesodhunt) |
Changed in procps (Ubuntu Lucid): | |
status: | Triaged → In Progress |
Changed in procps (Ubuntu Maverick): | |
status: | Triaged → In Progress |
Changed in procps (Ubuntu Natty): | |
status: | Triaged → In Progress |
Changed in procps (Ubuntu Maverick): | |
status: | Fix Committed → In Progress |
tags: | removed: verification-done verification-done-lucid |
tags: | added: bot-stop-nagging |
To post a comment you must log in.
In one customer's case, they changed their procps.conf start on criteria to: filesystems or started portmap)
start on (virtual-
This allowed these settings to be applied properly: udp_slot_ table_entries = 128 tcp_slot_ table_entries = 128
sunrpc.
sunrpc.
But all that does is workaround the issue. If you add another module later and put related entries in sysctl.conf, you still can't be sure they will apply correctly without testing it out. If it doesn't work, now you have to think about fiddling with jobs again (see Bug #690433 for example workarounds). It would be nice to find a way of automatically loading and/or reloading procps when appropriate.
For example procps.conf could have start on criteria something like: filesystems or NEEDS_PROCPS=1) filesystems or KERNEL_MOD=1)
start on (virtual-
or
start on (virtual-
Of course it would still be up to those other jobs to export KERNEL_MOD and I'm probably overlooking something that makes this a no good, horrible idea. But it helps illustrate the point, I think.