sysctl errors from bad /etc/sysctl.d conf files making packages uninstallable

Scott Ritchie scott at
Mon Nov 2 20:11:56 GMT 2009

Steve Langasek wrote:
> On Sun, Nov 01, 2009 at 01:28:20PM -0800, Scott Ritchie wrote:
>> The root cause is this: sysctl is throwing an error when it encounters
>> an /etc/sysctl.d/foo.conf file that contains keys it doesn't use.  How
>> these keys got onto the system is somewhat mysterious -- most likely
>> cause is they're conf files from an older version of some other package
>> (Wine's .conf file is a single line and works fine).
> That doesn't seem likely to me at all.  
> $ zgrep sysctl.d ~/ubuntu/dists/karmic/Contents-i386.gz |awk '{ print $NF }'|sort -u
> admin/procps
> multiverse/otherosfs/dosemu
> universe/misc/qemu-arm-static
> universe/otherosfs/wine,universe/otherosfs/wine1.2
> utils/tracker
> $ zgrep sysctl.d ~/ubuntu/dists/jaunty/Contents-i386.gz |awk '{ print $NF }'|sort -u
> admin/procps
> multiverse/otherosfs/dosemu
> universe/otherosfs/wine
> utils/tracker
> $ zgrep sysctl.d ~/ubuntu/dists/intrepid/Contents-i386.gz |awk '{ print $NF }'|sort -u
> base/procps
> universe/devel/glibc-source
> universe/otherosfs/wine
> utils/tracker
> $
> There are only a handful of packages in the archive using this facility. 
> Have you investigated what the actual files are that users have on their
> systems when running into this problem?

According to the bug report the errors were from keys that Wine never
created.  This means they were either there from another package or
added by the user.  From the sheer number of duplicates I got though it
seemed reasonable to conclude that this wasn't a case of someone
manually editing the file and forgetting - possibly there's some sort of
common script people were running out there as well.

>> This error propagates through upstart and causes dpkg --configure to
>> panic, making the package uninstallable.  This is obviously bad.
>> So it seems like we have 3 options:
>> 1) Quiet down sysctl so it doesn't throw these errors on unknown
>> commands.  As far as I can tell, it's undocumented if sysctl gives a
>> different exit status for unknown commands and genuine errors, so
>> there's no good way to tell them apart.
>> 2) Change procps upstart job to not care about sysctl errors.  I believe
>> debian does something similar.
>> 3) Change every package with a sysctl.d conffile to ignore start procps
>> errors (eg start procps || true).
> According to the manpage, 'sysctl -e' has the effect of ignoring key errors.
> That seems to me like the right place to handle this, instead of requiring
> other packages to ignore all errors from sysctl.

Do you mean changing the procps upstart job to invoke sysctl -e instead
of just sysctl?  That seems reasonable if upstart is going to ignore the
errors anyway.

Scott Ritchie

More information about the ubuntu-devel mailing list