Comment 12 for bug 1241376

Revision history for this message
Peter Cordes (peter-cordes) wrote :

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