procps fail to start

Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

Is there happening anything with this? I got the following errors now when I am trying to upgrade some packages.

invoke-rc.d: initscript procps, action "start" failed.
dpkg: error processing procps (--configure):
 subprocess installed post-installation script returned error exit status 1
No apport report written because the error message indicates its a followup error from a previous failure.
                                                                                                          dpkg: depend ency problems prevent configuration of udev:
 udev depends on procps; however:
  Package procps is not configured yet.
dpkg: error processing udev (--configure):
 dependency problems - leaving unconfigured
Setting up libssl-doc (1.0.1-4ubuntu5.9) ...
Setting up libssl-dev (1.0.1-4ubuntu5.9) ...
dpkg: dependency problems prevent configuration of openssh-server:
 openssh-server depends on procps; however:
  Package procps is not configured yet.
dpkg: error processing openssh-server (--configure):
 dependency problems - leaving unconfigured
Setting up libdrm2 (2.4.43-0ubuntu0.0.1) ...
No apport report written because the error message indicates its a followup error from a previous failure.

Status changed to 'Confirmed' because the bug affects multiple users.

This bug needs to get fixed.

I just installed Ubuntu 12.04 LTS (on a VPS) and noticed various package installs are failing (apt-get -V install ...)

The error is connected with this procps bug.

(1) procps fails to start:

# service start procps
start: Job failed to start

(2) if I manually try to start it, I get an error:

cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -
kernel.printk = 4 4 1 7
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
error: permission denied on key 'kernel.kptr_restrict'
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
vm.mmap_min_addr = 65536

I don't know how to resolve this error.

Are they any workarounds?

I just ran into the same issue. A simple workaround is to delete the file /etc/sysctl.d/10-kernel-hardening.conf

This has the rule: kernel.kptr_restrict = 1 which you can't do from an OpenVZ container.

Thanks a lot Danny! You saved my work!
Why is it that way? The error came up today for me. Yesterday was all fine....same server, same call...

I wonder what's going on these days with Ubuntu. Almost every update to 12.04 LTS seems to break something and cost me up to an hour each time. And yet again here... :(

More importantly:

Danny Lawson's fix DID NOT work for me (post #5 here), that is, removing the 10-kernel-hardening.config.

Sigh.

And, unfortunately, I can seem to get "start procps" to provide ANY sort of helpful debugging info.

OK, I'm getting this:

error: "Invalid argument" setting key "fs.inotify.max_user_watches"

in /var/log/upstart/procps.log

So, now I just need to figure out where this "max_user_watches" is being set. It doesn't appear to be in any of the /etc/sysctl.d/* files.

OK, I spoke to soon. Aparantly I grep'd for:

user_max

instead of max_user, which DOES match:

/etc/sysctl.d/30-spideroak.conf

I commented out the one line in this file (i.e. add a leading hash mark '#'), and now procps starts.

So, IF YOU USE SPIDEROAK, THIS MIGHT BE THE PROBLEM.

Hope this is helpful to others.

--Doug

Where is it decided who has permission to modify "kernel.kptr_restrict" ??

I encountered the error when running as root, so I am puzzled.

I also have a separate server running the identical version of 12.04 LTS (12.04.3) and it does not run into this error.
The problematic server was installed fresh a few days ago.
The other server has been running for about 1 month.

-- David

I am wondering if someone recently changed the behaviour of Ubuntu 12.04 (in 12.04.3)
so that kernel.kptr_restrict is always 1 and cannot be changed.

Notice:

# ls -l /prov/sys/kernel/kptr_restrict
-rw-r--r-- 1 root root 0 Oct 15 15:18 /proc/sys/kernel/kptr_restrict

# cat /proc/sys/kernel/kptr_restrict
1

If the value is already "1", then the line trying to set it to "1" can safely be commented out in this file:

/etc/sysctl.d/10-kernel-hardening.conf

Does anyone have any additional insights?

-- David

Danny Lawson's fix didn't work for me either. :-( And I have a slightly different result for that command:

# cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sudo sysctl -p -
kernel.printk = 4 4 1 7
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
kernel.yama.ptrace_scope = 1
vm.mmap_min_addr = 65536
net.core.wmem_max = 1048576
net.core.rmem_max = 1048576
net.core.wmem_default = 1048576
net.core.rmem_default = 1048576
error: "Invalid argument" setting key "net.ipv4.tcp_mem"
net.ipv4.tcp_rmem = 1048576
net.ipv4.tcp_wmem = 1048576
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.ip_forward = 1

Yes, in my case it was /etc/sysctl.d/30-iscsitarget.conf that was causing the problem.

procps was updated to procps:amd64 (3.2.8-11ubuntu6, 3.2.8-11ubuntu6.1) in my
 environment today.

Some keys doesn't work in a linux container (Ubuntu 12.04.3 LTS).
They work in my host which is also Ubuntu 12.04.3 LTS.

root@jian-local-machine-1:/home/ubuntu# cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -
error: permission denied on key 'kernel.printk'
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
error: permission denied on key 'kernel.kptr_restrict'
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
error: permission denied on key 'kernel.yama.ptrace_scope'
vm.mmap_min_addr = 65536

Following are the permission denied keys and their files.

root@jian-local-machine-1:/etc/sysctl.d# grep printk -r *
10-console-messages.conf:kernel.printk = 4 4 1 7

root@jian-local-machine-1:/etc/sysctl.d# grep kptr -r *
10-kernel-hardening.conf:kernel.kptr_restrict = 1

root@jian-local-machine-1:/etc/sysctl.d# grep ptrace_scope -r *
10-ptrace.conf:kernel.yama.ptrace_scope = 1

Doug, your Spider Oak file fix https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1157643/comments/11
worked for me! I returned it to normal after getting the install to work.

Doug's fixed mine too:

https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1157643/comments/11

I have the same symptoms like Jian reported in #14 and #15. – I fixed it (temp.) by commenting out the three lines in the three files (#15).

Same problem here. Found this error while doing a regular upgrade.

...
Setting up procps (1:3.2.8-11ubuntu6.1) ...
start: Job failed to start
invoke-rc.d: initscript procps, action "start" failed.
dpkg: error processing procps (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 procps
E: Sub-process /usr/bin/dpkg returned an error code (1)

$lsb_release -rd
Description: Ubuntu 12.04.3 LTS
Release: 12.04

Not sure if 100% related from the 8 server I tried to upgrade only two failed. This two servers are the only ones where I've tune vm.overcommit_memory creating "10-vm.overcommit_memory.conf" with "vm.overcommit_memory = 1".

/var/log/upstart/procps.log contains several "error: "Invalid argument" setting key "vm.overcommit_memory"

Same problem on my servers, after a regular update this morning.

$ lsb_release -rd
Description: Ubuntu 12.04.3 LTS
Release: 12.04

In my case, the errors logged in /var/log/upstart/procps.log are:
error: "Invalid argument" setting key "net.ipv4.conf.default.rp_filter"
error: "Invalid argument" setting key "net.ipv4.conf.all.rp_filter"

I need to turn off RP filtering. However, e.g. "sudo sysctl net.ipv4.conf.default.rp_filter=0" works fine.

The problem is the key (in my case: "net.ipv4.conf.default.rp_filter" or "net.ipv4.conf.all.rp_filter"). It does not matter whether it is set to 0 or 1, the problem is the definition (in my case: /etc/sysctl.d/10-network-security.conf). If the key is set, the start of the "procps" service fails. It worked fine before installing the update, i.e. the procps update is broken.

In my case /var/log/upstart/procps.log says:
error: "Invalid argument" setting key "kernel.shmmax"

kernel.shmmax is defined in /etc/sysctl.d/30-postgresql-shm.conf but it's commented out:
#kernel.shmmax = ...
#kernel.shmall = ...

I tried to rename kernel.shmmax to k_ernel.shmmax in case it doesn't detect it's a comment for some reason but that didn't make any difference.

I'm also on an OpenVZ container, my other boxes aren't affected by the bug.

Same problem on LXC containers. And https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1157643/comments/11 doesn't fix the issue for me.

The same as #12, tcp_mem, after upgrading to 6.1.

Disabled it in /etc/sysctl.d/30iscsitarget, it's rebooting now with a _large_ filesystem that's being fsck-ed :-(

Old physical box, no virtual funny things, plain 12.04 precise.

Instead of setting the max_user_watches in a separate file in /etc/sysctl.d, as spideroak seems to be doing,
you can define it in /etc/sysctl.conf.

If you define it this way, it won't cause any errors with procps and in addition it makes life easier if you have multiple realtime sync/backup applications running on your system (spideroak, Copy, dropbox, crashplan, whatever)

$ sudo vi /etc/sysctl.conf

# Increase max_user_watches, required for realtime backup/sync applications such as spideroak and crashplan
fs.inotify.max_user_watches=1048576

In addition to my other comment (#22):
I forgot to check /etc/sysctl.conf for kernel.shmmax.
The value was defined in there, I commented it out and the update went through afterwards.

This was helpful for me:

https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1157643/comments/9

root@desktop:/etc/sysctl.d# cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -
kernel.printk = 4 4 1 7
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
kernel.yama.ptrace_scope = 1
vm.mmap_min_addr = 65536
error: "Invalid argument" setting key "fs.inotify.max_user_watches"

root@desktop:/etc/sysctl.d# cat 30-spideroak.conf
fs.inotify.max_user_watches = 65536

Commented out, spideroak seems to continue working properly.

This appears to be a regression introduced by the recent fix to bug 1150413 being promoted yesterday.

To revert procps please run
$ sudo apt-get install procps=1:3.2.8-11ubuntu6

We will be opening a new bug shortly to deal with this regression.

On Wed, Oct 16, 2013 at 04:46:55PM -0000, Dave Chiluk wrote:
> This appears to be a regression introduced by the recent fix to bug
> 1150413 being promoted yesterday.

It's not a regression; users affected by this bug have a misconfigured
sysctl setup, which is non-fatal at boot but at package upgrade time causes
a package configuration failure.

> We will be opening a new bug shortly to deal with this regression.

No, please use the existing bug report.

So if I understand the whole context, procps start has always been broken in lxc (and maybe openvz too?) because the apparmor profile restricts writes to the kernel namespace. When called from upstart the failure to start is ignored. dpkg is not as forgiving, so trying to upgrade the package blows up because the service start step blows up. This started happening when the update to procps landed in precise-updates.

"<slangasek> sidnei: workarounds are possible (e.g., editing /usr/sbin/policy-rc.d to ignore requests for procps; or editing the config file in the container to comment out the problematic bits). A proper fix is going to take a bit."

With this patch,

root@c-saucy-0:~# sysctl -e kernel.yama.ptrace_scope=1
sysctl: permission denied on key 'kernel.yama.ptrace_scope'
root@c-saucy-0:~# echo $?
0

Without it, error code is 1.

So editing

/var/lib/dpkg/info/procps.postinst

inside the container and putting an

exit 0

on top of the file would be a safe workaround?

This bug causes juju to fail at installing on a local lxc host.

Status changed to 'Confirmed' because the bug affects multiple users.

This workaround worked for me. However iptables now seem to work quite strange. Valid config (it used to worked well in same containers) block outgoing connections but not incomming etc.
This happen on updated 12.04.3 on OpenVZ.
greetings.
~Filip

Hi there, I had the same problem. It was caused by some comments at the end of my custom sysctl file: E.g. in my (!) /etc/sysctl.d/10-custom-rules was a line "net.ipv4.tcp_fin_timeout = 15 # default 60". After I removed the comment it worked. Maybe this lines never worked, but they didn't throw any error before. C.

i have the same problem with openvz too. reason is, that the task procps return code 255. i have now fix the upstart task.

 in the file /etc/init/procps.conf i muster append

normal exit 0 TERM 255

to get the error code you can use:

cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -
echo $?

than you can use the error code for normal exit.

i think the postinst should ignore the task status.

Hello purity, or anyone else affected,

Accepted procps into raring-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/procps/1:3.3.3-2ubuntu5.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello purity, or anyone else affected,

Accepted procps into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/procps/1:3.2.8-11ubuntu6.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello purity, or anyone else affected,

Accepted procps into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/procps/1:3.3.3-2ubuntu3.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello purity, or anyone else affected,

Accepted procps into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/procps/1:3.3.3-2ubuntu8 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

so i have test you new version.

# dpkg -i procps_3.3.3-2ubuntu5.2_amd64.deb libprocps0_3.3.3-2ubuntu5.2_amd64.deb
(Lese Datenbank ... 41544 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Ersetzen von procps 1:3.2.8-11ubuntu6 (durch procps_3.3.3-2ubuntu5.2_amd64.deb) ...
Ersatz für procps wird entpackt ...
Vormals nicht ausgewähltes Paket libprocps0 wird gewählt.
Entpacken von libprocps0 (aus libprocps0_3.3.3-2ubuntu5.2_amd64.deb) ...
libprocps0 (1:3.3.3-2ubuntu5.2) wird eingerichtet ...
procps (1:3.3.3-2ubuntu5.2) wird eingerichtet ...
procps stop/waiting
Trigger für man-db werden verarbeitet ...
Trigger für libc-bin werden verarbeitet ...
ldconfig deferred processing now taking place

# start procps
procps stop/waiting

# echo $?
0

# cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -
kernel.printk = 4 4 1 7
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
sysctl: permission denied on key 'kernel.kptr_restrict'
sysctl: permission denied on key 'kernel.sysrq'
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
vm.mmap_min_addr = 65536

# echo $?
0

that looks very good. no permission denied error.

On Thu, Oct 17, 2013 at 06:47:47AM -0000, Filip D wrote:
> However iptables now seem to work quite strange.

This is unrelated. We have double-checked the code, and the only change
here is to the return value of sysctl; all of the configured sysctl options
were being applied before the change, and they are still being applied in
the same way after the change, with the only difference now being the
overall success/failure return code of the usptart job.

iptables is in any case not managed by sysctl.

Confirmed on precise.

Tested on all affected releases, since this is a critical fix for a regression, I'll now ignore the SRU waiting period and release directly.

This bug was fixed in the package procps - 1:3.2.8-11ubuntu6.2

---------------
procps (1:3.2.8-11ubuntu6.2) precise; urgency=low

  * ignore_eaccess.patch: If we get eaccess when opening a sysctl file for
    writing, don't error out. Otherwise package upgrades can fail, especially
    in containers. (LP: #1157643)
 -- Serge Hallyn <email address hidden> Wed, 16 Oct 2013 13:45:48 -0500

This bug was fixed in the package procps - 1:3.3.3-2ubuntu3.2

---------------
procps (1:3.3.3-2ubuntu3.2) quantal; urgency=low

  * ignore_eaccess.patch: If we get eaccess when opening a sysctl file for
    writing, don't error out. Otherwise package upgrades can fail, especially
    in containers. (LP: #1157643)
 -- Serge Hallyn <email address hidden> Wed, 16 Oct 2013 13:45:48 -0500

This bug was fixed in the package procps - 1:3.3.3-2ubuntu5.2

---------------
procps (1:3.3.3-2ubuntu5.2) raring; urgency=low

  * ignore_eaccess.patch: If we get eaccess when opening a sysctl file for
    writing, don't error out. Otherwise package upgrades can fail, especially
    in containers. (LP: #1157643)
 -- Serge Hallyn <email address hidden> Wed, 16 Oct 2013 13:45:48 -0500

This bug was fixed in the package procps - 1:3.3.3-2ubuntu8

---------------
procps (1:3.3.3-2ubuntu8) saucy; urgency=low

  * ignore_eaccess.patch: If we get eaccess when opening a sysctl file for
    writing, don't error out. Otherwise package upgrades can fail, especially
    in containers. (LP: #1157643)
 -- Serge Hallyn <email address hidden> Wed, 16 Oct 2013 13:45:48 -0500

I tested it on saucy Desktop with:
sudo start procps
and:
sudo -s
cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -
and both results of echo $? were 0

I then created a lxc container:
sudo lxc-create -t ubuntu -n saucy -- -r saucy
sudo lxc-start -n saucy
and updated the packaged to 1:3.3.3-2ubuntu8 through wget both procps and libprocps0

And for good measure I did the same for precise:
sudo lxc-create -t ubuntu -n precise -- -r precise
sudo lxc-start -n precise
and I updated to 1:3.2.8-11ubuntu6.2 for procps

The same results in both cases:
cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -
echo $? returns 0

Hope it gets to update soon ;)

In my cast, it's the same with Tudor Holton (tudor) , the error is :
kernel.printk = 4 4 1 7
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
kernel.yama.ptrace_scope = 1
vm.mmap_min_addr = 65536
net.core.wmem_max = 1048576
net.core.rmem_max = 1048576
net.core.wmem_default = 1048576
net.core.rmem_default = 1048576
error: "Invalid argument" setting key "net.ipv4.tcp_mem"
net.ipv4.tcp_rmem = 1048576
net.ipv4.tcp_wmem = 1048576

I found 'net.ipv4.tcp_mem=1048576' in /etc/sysctl.d/30-iscsitarget.conf. As i never changed this 30-iscsitarget.conf file, So it should be a bug from iscsitarget package which i just install recently.

I changed 'net.ipv4.tcp_mem=1048576' to 'net.ipv4.tcp_mem=1048576 87380 6291456', then it's ok.
Seems net.ipv4.tcp_mem needs three value separated by spaces, not one value.
I took the three value '1048576 87380 6291456' from /proc/sys/net/ipv4/tcp_rmem.

30-iscsitarget.conf set net.ipv4.tcp_rmem to 1048576, but it's ok for this one.

Fixed for me with LXC and Ubuntu 12.04.3. – Thanks a lot! :)

This bug was fixed in the package procps - 1:3.3.3-2ubuntu8

---------------
procps (1:3.3.3-2ubuntu8) saucy; urgency=low

  * ignore_eaccess.patch: If we get eaccess when opening a sysctl file for
    writing, don't error out. Otherwise package upgrades can fail, especially
    in containers. (LP: #1157643)
 -- Serge Hallyn <email address hidden> Wed, 16 Oct 2013 13:45:48 -0500

Doug Morse's comment #9 fixed it for me. I have SpiderOak. Running on 12.04 LTS Kubuntu. Thank you, Doug!

A work around: (on Ubuntu 12.04.3 LTS (Precise))

> sudo mv /etc/init/procps.conf /etc/init/procps.conf.old
procps 1:3.2.8-11ubuntu6.2 .. after renaming procps.conf the install finished without error

I realize this was reported fixed in: 1:3.3.3-2ubuntu8 (saucy)
But I don't want to upgrade (right now)

Comment #25 solve the problem for me and finally I could update procps to the fixed version (1:3.2.8-11ubuntu6.2) in Ubuntu 12.04.3

Are there any downsides with this solution versus the one explained in comment #9?

I forgot to mention that I also have SpiderOak in my pc :)

I have spideroak. #25 and #9 did not resolve it for me.

root@jeeves:~# cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -
kernel.printk = 4 4 1 7
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
kernel.yama.ptrace_scope = 1
vm.mmap_min_addr = 65536
net.core.wmem_max = 1048576
net.core.rmem_max = 1048576
net.core.wmem_default = 1048576
net.core.rmem_default = 1048576
error: "Invalid argument" setting key "net.ipv4.tcp_mem"
net.ipv4.tcp_rmem = 1048576
net.ipv4.tcp_wmem = 1048576
fs.inotify.max_user_watches = 65536

apporc #55 resolved for me

I changed 'net.ipv4.tcp_mem=1048576' to 'net.ipv4.tcp_mem=1048576 87380 6291456', then it's ok. in 30-iscsitarget.conf

Same as #62. #55 solved it for me too. Should we file a bug against iscsitarget=1.4.20.2-5ubuntu3.3 ?

Latest upgrade attempt for 12.04 (no work-arounds) was not successful. Additional info:

cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sudo sysctl -p -

kernel.printk = 4 4 1 7
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
kernel.kptr_restrict = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
kernel.yama.ptrace_scope = 1
vm.mmap_min_addr = 65536
fs.inotify.max_user_watches = 524288
error: "Invalid argument" setting key "fs.inotify.max_user_watches"

grep fs.inotify.max_user_watches /etc/sysctl.d/*.conf

/etc/sysctl.d/30-nepomuk-inotify-limit.conf:fs.inotify.max_user_watches = 524288
/etc/sysctl.d/30-spideroak.conf:fs.inotify.max_user_watches = 65536

Now, the curious item here is the nepomuk entry. I may have launched it once just to look at it, but I do not actively use this application.

Thanks to https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1157643/comments/11 like #16 and #17 now I don't get "Broken Count >0" error and I'm able to manage my packages. But it is a temp. solution...

#59 solve elegantly the problem ... just do :

> sudo mv /etc/init/procps.conf /etc/init/procps.conf.old

(+ Aptitude upgrade)

Thanks William !

francois1:
note that the workaround does not fix the problem of procps failing to start via upstart,etc
It only allows the dpgk process to complete the install/upgrade process with out 'hoseing' the system.
if you rename procps.conf.old back to procps.conf it will still fail.

2nd workaround:
> I downloaded (procps & libprocps0) [1:3.3.3-2ubuntu7] from
> http://packages.ubuntu.com/saucy/procps
> http://packages.ubuntu.com/saucy/libprocps0
> and manually installed the updated version
** this correct the underlying problem, and you can rename procps.conf.old propps.conf

Thanks to #59 now the updgrade runs successfully, but on command "sudo service procps status" I get "procps: unrecognized service".

Other informations:

sudo ls -l /etc/init.d/ | grep procps
OUTPUT:
lrwxrwxrwx 1 root root 21 ott 17 16:50 procps -> /lib/init/upstart-job

sudo ls -l /lib/init/upstart-job
OUTPUT:
ls: impossibile accedere a /lib/init/upstart-job: File o directory non esistente
(Unable to access to /lib/init/upstart-job: File or directory does not exist)

upstart-job doesn't exist...why?? -.-

#68 when you have do the work around from #59 you have rename the service file. you must revert the change.

I tried the 2nd work around from #67:
 > I downloaded (procps & libprocps0) [1:3.3.3-2ubuntu7] from
> http://packages.ubuntu.com/saucy/procps
> http://packages.ubuntu.com/saucy/libprocps0
> and manually installed the updated version

And now I am stuck:

$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... failed.
The following packages have unmet dependencies:
 procps : Depends: sysv-rc (>= 2.88dsf-24) but 2.88dsf-13.10ubuntu11.1 is installed or
                   file-rc (>= 0.8.16) but it is not installable
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
E: Unable to correct dependencies

How can I get out of this? Thanks.

On Sat, Oct 26, 2013 at 01:02:39AM -0000, Cao Minh Tu wrote:
> How can I get out of this?

By installing the version of procps for your release, which is the one in
precise-updates, not in saucy.

Doud Morse's fix (Comment #9) worked for me. Solved at 2:47am. Gosh, I love computers!

Doug Mors's fix (Comment #9) worked for me too.
So the problem seems partialy related to spideroak.

Tested with Ubuntu 12.04.3 LTS, procps/precise-updates uptodate 1:3.2.8-11ubuntu6.2:

In /etc/sysctl.d/10-network-security.conf:
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

$ sudo service procps start
start: Job failed to start

After commenting out the lines in /etc/sysctl.d/10-network-security.conf:
# net.ipv4.conf.default.rp_filter=0
# net.ipv4.conf.all.rp_filter=0

$ sudo service procps start
procps stop/waiting

That is, the bug is still there and -- regardless of the value of the rp_filter setting (0 or 1) -- it is not working.

Same than #74 - the bug is still there.

"sudo service procps start" fails with (/var/log/upstart/procps.log):

error: "Invalid argument" setting key "vm.overcommit_memory"
error: "Invalid argument" setting key "vm.overcommit_memory"

Upgrade to Spideroak 5.0.4 seems to have fixed it for me (running 12.04.3 LTS)

Hi,

I had (before update) Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-41-generic x86_64). I did

sudo apt-get update
sudo apt-get dist-upgrade

The system proposed some updates and one of them was also procps

Get:32 http://nl.archive.ubuntu.com/ubuntu/ precise-updates/main procps amd64 1:3.2.8-11ubuntu6.2 [235 kB]

At the end of the procedure the machine returned

Setting up procps (1:3.2.8-11ubuntu6.2) ...
start: Job failed to start
invoke-rc.d: initscript procps, action "start" failed.
dpkg: error processing procps (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of udev:
 udev depends on procps; however:
  Package procps is not configured yet.
dpkg: error processing udev (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of mdadm:
 mdadm depends on udev (>= 136-1); however:
  Package udev is not configured yet.
dpkg: error processing mdadm (--configure):
 dependency problems - leaving unconfigured
Setting up bash-completion (1:1.3-1ubuntu8.1) ...
No apport report written because the error message indicates it's a follow-up error from a previous failure.
                            No apport report written because the error message indicates it's a follow-up error from a previous failure.
                                                        Installing new version of config file /etc/bash_completion.d/tar ...
Setting up samba-common-bin (2:3.6.3-2ubuntu2.8) ...
dpkg: dependency problems prevent configuration of samba:
 samba depends on procps; however:
  Package procps is not configured yet.
dpkg: error processing samba (--configure):
 dependency problems - leaving unconfigured
Setting up smbclient (2:3.6.3-2ubuntu2.8) ...
No apport report written because MaxReports has already been reached
                                                                    Setting up libpam-smbpass (2:3.6.3-2ubuntu2.8) ...
Setting up rsyslog (5.8.6-1ubuntu8.5) ...
Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
rsyslog stop/waiting
rsyslog start/running, process 9224
Setting up libplymouth2 (0.8.2-2ubuntu31.1) ...
dpkg: dependency problems prevent configuration of plymouth:
 plymouth depends on udev (>= 166-0ubuntu4); however:
  Package udev is not configured yet.
dpkg: error processing plymouth (--configure):
 dependency problems - leaving unconfigured
No apport report written because MaxReports has already been reached
                                                                    Setting up apt-transport-https (0.8.16~exp12ubuntu10.15) ...
dpkg: dependency problems prevent configuration of plymouth-theme-ubuntu-text:
 plymouth-theme-ubuntu-text depends on plymouth; however:
  Package plymouth is not configured yet.
dpkg: error processing plymouth-theme-ubuntu-text (--configure):
 dependency problems - leaving unconfigured
Setting up apt-xapian-index (0.44ubuntu5.1) ...
No apport report written because MaxReports has already been reached
                                                                    Setting up binutils (2.22-6ubuntu1.1) ...
done
dpkg: dependency problems prevent configurati...

BroZ69, please file a new bug report for your issue and attach the contents of /var/log/upstart/procps.log to your report. You are likely experiencing a different bug than this one.

With SpiderOak 5.0.4 installed and the nepomuk entry for 'fs.inotify.max_user_watches = 524288' commented out, the latest procps update (1:3.2.8-11ubuntu6.3) installed without error on my Ubuntu 12.04 desktop and upstart successfully started. I'll try uncommenting the nepomuk entry now.

I can also confirm Upgrade to Spideroak 5.0.4 (via deb download) removed the problem.

I was having update problems and dpkg would not configure
 procps
 samba
 apport-gtk

Found that procps fails to start, and ran command manually

cat /etc/sysctl.d/*.conf /etc/sysctl.conf | sysctl -e -p -

Gave key permission problems. I eventually found this bug report and the mentions re spideroak. Updated spideroak and the problem went away.

Thanks for the tip about Spideroak update through their apt download; that also worked for me (running 64b 12.04.3 LTS).

Doug's #9 worked for me. I really appreciated it since I was just about ready to give up when my son found this work-around.

After an apt-get update && apt-get upgrade on my VPS (Ubuntu 12.04.5 LTS - 3.13.0-32-generic x86_64) I'm facing this:

Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
3 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue [Y/n]? y
Setting up procps (1:3.2.8-11ubuntu6.4) ...
start: Job failed to start
invoke-rc.d: initscript procps, action "start" failed.
dpkg: error processing procps (--configure):
 subprocess installed post-installation script returned error exit status 1
No apport report written because MaxReports is reached already
                                                              dpkg: dependency problems prevent configuration of udev:
 udev depends on procps; however:
  Package procps is not configured yet.
dpkg: error processing udev (--configure):
 dependency problems - leaving unconfigured
No apport report written because MaxReports is reached already
                                                              dpkg: dependency problems prevent configuration of mountall:
 mountall depends on udev; however:
  Package udev is not configured yet.
dpkg: error processing mountall (--configure):
 dependency problems - leaving unconfigured
No apport report written because MaxReports is reached already
                                                              Errors were encountered while processing:
 procps
 udev
 mountall
E: Sub-process /usr/bin/dpkg returned an error code (1)

I tried different approaches found on the internet regarding this issue but none worked for me.

sudo /etc/init.d/procps restart
stop: Unknown instance:
procps stop/waiting

It looks like you are encountering an issue with the procps package during the upgrade process on an Ubuntu 12.04.2 LTS system. The error seems to be related to the sysctl program failing when it can't write to certain keys, resulting in the procps upstart job failing to start.

The proposed solution involves updating the procps package to address the permission errors in the sysctl program. Here's a step-by-step breakdown of the proposed solution:

Set up precise in an lxc container:
Create a container using the precise release of Ubuntu.

Apply updates from the -updates pocket:
Update the system within the container using the -updates repository.

Observe that the procps package fails to install:
Note the failure of the procps package installation.

Enable -proposed:
Enable the -proposed repository to access proposed updates.

Install the procps package from -proposed:
Install the updated procps package from the -proposed repository.

Observe that the package upgrades successfully:
Confirm that the procps package upgrade is successful after applying the proposed updates.

Regression potential:
The patch changes the behavior of the sysctl program, making permission errors non-fatal. There's a note about potential regression for anything relying on the current behavior, especially when sysctl is run by a non-root user. However, it's mentioned that sysctl is not meant to be invoked by non-root users.

In your case, it seems like the issue is related to permission errors on the 'kernel.kptr_restrict' key. The proposed update should address this and allow procps to start successfully.

Before proceeding, make sure to backup important data, and if possible, test the proposed solution in a controlled environment to ensure compatibility with your system configuration.

To apply the proposed solution, you can follow the provided test case steps on your system. If you encounter any issues or have further questions, feel free to ask for assistance. Answer Credit https://checkricepurity.com/