Re: Bug#546680: man-db: start-stop-daemon: Unable to alter IO priority to mask 24583 (Operation not permitted)
Hi!
On Thu, 2009-09-24 at 13:27:52 +0100, Colin Watson wrote:
> 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?
Yeah, I considered doing something like this when I first saw your
vserver related change to man-db, and I guess this is just going to be
worse as more packages use the s-s-d io scheduling support.
It also needs to ignore ENOSYS, for old Linux kernels which do not
support the syscall, ESRCH should not be a problem as we always call
it for the current process. The remaining one is EINVAL which might
make sense to trap an exit fatally, but OTOH this is not supported on
non-Linux kernels so not just warning on any error should be fine as
well. That's what I've gone with for now:
<http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=6d365230>
will be in next dpkg 1.15.5.
> > 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.)
And I wholeheartedly agree with this.
thanks,
guillem
Reply to: