Re: Bug#546680: man-db: start-stop-daemon: Unable to alter IO priority to mask 24583 (Operation not permitted)

[Colin Watson <cjwatson@debian.org>]

On Tue, Sep 15, 2009 at 11:05:16AM +1000, Daniel Pittman wrote:
> G'day.  I don't know if this is correctly a man-db bug, or a dpkg bug:
> 
> Since man-db has started using start-stop-daemon in the daily and weekly
> cron.d scripts it has been failing to run inside the OpenVZ containers I use
> to provide "virtual" machines for a bunch of services.
> 
> Specifically, this failure:
> 
> /etc/cron.daily/man-db:
> start-stop-daemon: Unable to alter IO priority to mask 24583 (Operation not permitted)
> run-parts: /etc/cron.daily/man-db exited with return code 2

I can sort of understand why start-stop-daemon feels that it ought to do
what was asked for. However, I must say that it's awfully inconvenient
for each client package to have to work around this kind of thing; I've
run across it in man-db and openssh-server so far. dpkg folks, what do
you think about silently ignoring EPERM here?

> The second line is no great surprise: within the virtual environment (VE)
> access to various kernel level features, including setting your own I/O
> priority, is deliberately restricted.

(For the record I think it's slightly silly for them to restrict the
ability to *lower* I/O priority.)

> Having the man-db nightly processes run with a lower I/O priority is nice, but
> at this point it doesn't run them at all inside the VE because of this
> invocation.
> 
> It would be good to consider that a non-fatal error.  I notice, in fact, that
> man-db already tries to work around the free 'vserver' environment.
> 
> If you want to continue to do that I suggest either using the 'virt-what'
> tool, which makes it a problem for someone /else/ to identify every new VM
> type out there, or to make the failure to set an I/O scheduler non-fatal.

I don't really want to drag a new package into the base system even if
it is small; and presumably I would have to keep track of which kinds of
VMs permit changing I/O priority.

> However, to detect running inside an OpenVZ VE you can check for
> /proc/user_beancounters (deprecated, but present), or /proc/vz/{veinfo,vestat}
> existing.
> 
> Determining the different between the "hardware" node, which can set I/O
> priority, and the VE, which can't, is best done by checking for the absence of
> /proc/vz/version, I think.

virt-what appears to use [ -d /proc/vz -a ! -d /proc/bc ] for this. I'll
do that for now, I think.

Thanks,

-- 
Colin Watson                                       [cjwatson@debian.org]