Bug #1241376 “procps (1:3.2.8-11ubuntu6.1) upgrade error” : Bugs : procps package : Ubuntu

Revision history for this message

Philipp Noack (philipp-noack-b) wrote on 2013-10-18:

#1

Sorry I fixed it with moving /etc/sysctl.d/30-iscsitarget.conf of the folder and then upgrading.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2013-10-18:

#2

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

Changed in procps (Ubuntu):
status:	New → Confirmed

Revision history for this message

Kees Bakker (keestux) wrote on 2013-10-18:

#3

The 6.2 update only had a fix for a container environment. But that doesn't help other cases, such as 30-iscsitarget.conf which has a setting for net.ipv4.tcp_mem. The error message is:
error: "Invalid argument" setting key "net.ipv4.tcp_mem"

Another system of mine had a problem with 10-kernel-hardening.conf with setting for kernel.kptr_restrict. The 6.1 update caused a "permission denied" error and procps to fail. I wasn't yet able to verify whether the recent 6.2 update solves it.

Revision history for this message

Timur Alperovich (timur-alperovich) wrote on 2013-10-21:

#4

When upgrading procps from 1:3.2.8-11ubuntu6 to 1:3.2.8-11ubuntu6.2, the upgrade fails with the errors similar to the ones reported above:

timur@test:~$ sudo apt-get install procps=1:3.2.8-11ubuntu6.2
Reading package lists... Done
Building dependency tree
Reading state information... Done
procps is already the newest version.
The following packages were automatically installed and are no longer required:
linux-headers-3.2.0-51 linux-image-3.2.0-51-virtual linux-headers-3.2.0-51-virtual
Use 'apt-get autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
1 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.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
Errors were encountered while processing:
procps
E: Sub-process /usr/bin/dpkg returned an error code (1)

Looking at the upstart logs from procps, the error is:

error: "Invalid argument" setting key "net.ipv4.tcp_keepalive_intvl"

The actual entry in /etc/sysctl.d is:
net.ipv4.tcp_keepalive_intvl = 10<EOF>

If I place a newline before the <EOF> in the file, the script parses it correctly. If other reported cases are similar, then I'm guessing the bug is not in this package.

Revision history for this message

Vincent Cautaerts (vincent-cautaerts) wrote on 2013-10-25:

#5

I also had this problem.

In my case, the file

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

was no finished by a newline.

After adding the newline at the end, the upgrade of 'procps' worked.

Revision history for this message

Galen Thurber (godfree2) wrote on 2013-10-25:

#6

I had the same as Vincent
/etc/sysctl.d/30-spideroak.conf
it did not have a new line at the end of the file

After checking all .conf files and made sure they had a new line at the end of the file, upgrade now works.
Other procedures mentioned on launchpad and forums ended up working because people added a new line not by changing variables.

good find Timur

Revision history for this message

Christopher (cwkeller) wrote on 2013-10-25:

#7

same solution here.
in upstart/procps.log had error: "Invalid argument" setting key "fs.inotify.max_user_watches"
which is the only entry in 30-spideroak.conf
Thanks to all.
Chris

Revision history for this message

Ryan Castellucci (ryanc-palantir) wrote on 2013-10-30:

#8

I also got burned by this with net.ipv4.tcp_mem in 30-iscsitarget.conf.

Revision history for this message

juanmatias (juanmatias) wrote on 2013-11-04:

#9

Hi, all.

I had this issue today and after read this thread I "cat"ed /etc/sysctl.d/30-SpiderOak.conf and I discovered that this file has no new line at the end. Just added a new line and then the upgrade worked ok.

I deinstalled Spider Oak a time ago, so I think I can remove this file.

I'm using elementaryOS:
uname -a
Linux jdelacamara-POSITIVO-BGH 3.2.0-55-generic #85-Ubuntu SMP Wed Oct 2 12:29:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Thanks.

Revision history for this message

Jus Lim (honeybeeworld) wrote on 2013-11-05:

#10

/30-spideroak.conf was also a problem for me. There was a newline before EOF, but I had to change fs.inotify.max_user_watches from 65536 to 65535, and then was able to install procps.

Revision history for this message

Philipp Noack (philipp-noack-b) wrote on 2013-11-06:

#11

After another unattended update of procps has failed this morning I figured out that "net.ipv4.tcp_mem in 30-iscsitarget.conf" causes an error and prevents procps from starting - like Ryan already said. Commenting out that line is a workaround.

Revision history for this message

Peter Cordes (peter-cordes) wrote on 2013-11-26:

#12

(copied from my comment in bug 1247921, since this is the exact bug I had, and more people are looking at this)

I ran into this today, and eventually (thanks to strace!) figured out that I had a config file that didn't end with a newline. 30-SpiderOak, like several other people, actually. So what was getting fed to sysctl was actually

fs.inotify.max_user_watches = 65536fs.inotify.max_user_watches = 65536

(yes, two files in a row were setting the same value, but the first one didn't end with a newline).

So sysctl opened /proc/sys/fs/inotify/max_user_watches, and wrote "65536fs.inotify.max_user_watches = 65536" to it. Then printed an error, and exited with a non-zero status, making the upstart job fail.

So, biggest problem here is that the upstart job shouldn't fail if you have one bad line in one config file. warning somehow would be excellent, but I think most people would rather not have their whole package upgrade chain blocked while they sort this out.

Admittedly, I probably wouldn't have noticed it at all if it hadn't blocked dpkg, and I was only ok because other lines were also setting the same key. If this had been something important for security, I might not be arguing that the upstart job should be cat | sysctl; true

Printing the key value would probably be a good idea, too, that would have saved me a bunch of debugging after I found where upstart stores its scripts and logs. (I feel old for being used to good old init.d scripts that I could run manually to see their output... Hey upstart, get off of my lawn. Although honestly the format of the files in /etc/init/ is very easy to understand, I found the script portion without any trouble so I could still just run what the script was trying to do.)

I tried a bunch of different inputs to sysctl, including noticing that I got no errors if I fed it the config files one at a time with for i in /etc/sysctl.d/* /etc/sysctl.conf; do echo $i;sudo sysctl -e -p "$i";done. As I said, I didn't figure out that I had a file not ending in newline until I ran cat ... | sudo sysctl -e -p - 2>&1 | less

I feel like this could have been a lot easier to debug with better error messages, even leaving aside that I had to learn my way around upstart at the beginning of this. Oh, and to figure out that the procps postinst script was trying to start an upstart job called procps. I wasn't 100% sure from the error messages. (although now that I look at the invoke-rc.d line, it does say it was the procps init script.)

So, bottom line, procps init script should probably not fail when the only errors are invalid values for keys. It already ignores unknown keys, with the -e option. Maybe sysctl needs an option to ignore errors of the other kind? Although if a key exists, errors assigning to it are much more likely to be a problem, so you do want to at least warn, but don't want to ignore them or trainwreck dpkg / apt.

(copied from my comment in bug 1247921, since this is the exact bug I had, and more people are looking at this)

I ran into this today, and eventually (thanks to strace!) figured out that I had a config file that didn't end with a newline. 30-SpiderOak, like several other people, actually.  So what was getting fed to sysctl was actually