Re: perl 5.20.2-3+deb8u6
On Wed, 27 Jul 2016 16:32:28 +0300
Eugene Berdnikov <bd4@protva.ru> wrote:
> On Wed, Jul 27, 2016 at 12:55:37PM +0300, Victor Wagner wrote:
> >
> > Тут при установке очередного секьюрити-апдейта perl возникла
> > проблема
> >
> > Cannot write to /usr/bin/cpan: Device or resource busy.
> ...
> > 1. Сначала руками поставить perl-base - возникает та же ошибка на
> > другом исполняемом файле (/usr/bin/perl)
>
> Выглядит так, как будто эти файлы кто-то держит открытыми по mmap(),
> а инсталлятор пытается открыть их на запись. Для файла /usr/bin/cpan
> это вообще очень странно, потому что это не бинарник, а перловый
> скрипт, он не должен mmap-иться при запуске. Покажите выдачу
>
> fuser -v /usr/bin/cpan
> fuser -v /usr/bin/perl
Ничего хорошего оно не показало. В смысле, пусто, никто файл не держит.
>
> Инсталлятор тоже не должен открывать на запись существующие файлы,
> он должен создавать временный файл, записывать в него новую версию,
> затем делать атомарный rename(2). Я бы посмотрел результат
>
Попытка сделать атоммарный unlink (в смысле rm) дала ту же ошибку.
Что характерно, на двух серверах, которые я все же решился сапгрейдить,
апгрейд прошел без проблем. У одного архитектура amd64, у другого armhf.
То же самое - в LXC-контейнере с i386.
Общее у всех этих трех систем - там не было X-ов, lightdm и lxde.
> strace -o /tmp/upd.strace aptitude install perl-...
> egrep '/usr/bin/(perl|cpan)' /tmp/upd.strace
>
> а потом поковырял /tmp/upd.strace на предмет того, из какого
> подпроцесса выполняются сисколы, вызывающие ошибку. Если ошибку
> вызывает rename(), то скорее всего в ядре включены какие-то вычурные
> опции security.
Ядро дистрибутивное, ничего необычного вроде нет.
--
Victor Wagner <vitus@wagner.pp.ru>
Reply to: