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

[Scott Ritchie]

A lot of users are running across the Wine package failing to install
and causing a whole system mess:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/447197

At first I thought the issue was an old maintainer script that called
/etc/init.d/procps start manually.  However, transitioning this script
to upstart with start procps, as well as reverting it to invoking sysctl
directly causes the same issue.

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

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

At the moment, installing a package like Wine is the only way a user
will notice this error - upstart won't let a failing procps job prevent
system bootup.  I could hack around this by using option 3 for the Wine
package, but the problem will likely crop up elsewhere later.

It's also not clear how sysctl is dealing with the error at the moment -
quite possibly, sysctl is giving up the first time it sees a bad key,
meaning later keys are never loaded (possible security implications).

Either way, I believe some coordination here will be important to
getting this handled well, so I've cced the Debian procps maintainer as
well.  Thanks for your time :)

Thanks,
Scott Ritchie

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

[Steve Langasek-6]

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?

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

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@...                                     vorlon@...


--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

[Scott Ritchie]

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.

Thanks,
Scott Ritchie

--
ubuntu-devel mailing list
ubuntu-devel@...
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel