[sisyphus] Потрясающая диагностика в hasher

[sisyphus] Потрясающая диагностика в hasher

[Yury Aliaev]

Всем доброго времени суток!

Время от времени при попытке пересобрать пакеты напарываюсь на следующее 
(словом kosyak у меня всего лишь называется скрипт, вызыающий hsh с 
нужным рабочим каталогом):

[mutabor@builder SRPMS]$ kosyak kernel-source-comedi-0.7.76-alt1.src.rpm
lzop: <stdin>: Compressed data violation
/.host/cpio: premature end of file
hsh-initroot: Unpack of 
/tmp/.private/mutabor/hasher-SS/cache/chroot/chroot.cpio.lzo failed.

Вы думаете, srpm'ка битая? Ага, я тоже поначалу так думал! Как бы не так!:

[mutabor@builder SRPMS]$ rm -rf /tmp/.private/mutabor/hasher-SS/*

(там у меня рабочий каталог находится)

[mutabor@builder SRPMS]$ kosyak kernel-source-comedi-0.7.76-alt1.src.rpm
<13>Jan 26 09:52:10 rpmi: setup-2.2.12-alt1 installed
<13>Jan 26 09:52:10 rpmi: filesystem-2.3.3-alt1 installed
<13>Jan 26 09:52:10 rpmi: glibc-preinstall-6:2.9-alt2 installed
<13>Jan 26 09:52:10 rpmi: glibc-core-6:2.9-alt2 installed
<13>Jan 26 09:52:10 rpmi: sh-3.2.39-alt2 installed
<13>Jan 26 09:52:10 rpmi: bzlib-1:1.0.5-alt3 installed
<13>Jan 26 09:52:10 rpmi: zlib-1.2.3-alt5 installed
<13>Jan 26 09:52:10 rpmi: libpopt-1:1.14-alt4 installed
...

И всё прекрасно понеслось...

Остаются вопросы: 1) почему так происходит? и 2) почему hasher выдаёт 
такую странную ошибку, по логике он должен бы писать что-то вроде "у вас 
рабочий каталог протух".

Юрий.

Re: [sisyphus] Потрясающая диагностика в hasher

[Boris Savelev]

26 января 2009 г. 12:56 пользователь Yury Aliaev <mutab0r@rambler.ru> написал:
> Всем доброго времени суток!
>
> Время от времени при попытке пересобрать пакеты напарываюсь на следующее
> (словом kosyak у меня всего лишь называется скрипт, вызыающий hsh с нужным
> рабочим каталогом):
>
> [mutabor@builder SRPMS]$ kosyak kernel-source-comedi-0.7.76-alt1.src.rpm
> lzop: <stdin>: Compressed data violation
> /.host/cpio: premature end of file
> hsh-initroot: Unpack of
> /tmp/.private/mutabor/hasher-SS/cache/chroot/chroot.cpio.lzo failed.
>
> Вы думаете, srpm'ка битая? Ага, я тоже поначалу так думал! Как бы не так!:
>
> [mutabor@builder SRPMS]$ rm -rf /tmp/.private/mutabor/hasher-SS/*
>
> (там у меня рабочий каталог находится)
>
> [mutabor@builder SRPMS]$ kosyak kernel-source-comedi-0.7.76-alt1.src.rpm
> <13>Jan 26 09:52:10 rpmi: setup-2.2.12-alt1 installed
> <13>Jan 26 09:52:10 rpmi: filesystem-2.3.3-alt1 installed
> <13>Jan 26 09:52:10 rpmi: glibc-preinstall-6:2.9-alt2 installed
> <13>Jan 26 09:52:10 rpmi: glibc-core-6:2.9-alt2 installed
> <13>Jan 26 09:52:10 rpmi: sh-3.2.39-alt2 installed
> <13>Jan 26 09:52:10 rpmi: bzlib-1:1.0.5-alt3 installed
> <13>Jan 26 09:52:10 rpmi: zlib-1.2.3-alt5 installed
> <13>Jan 26 09:52:10 rpmi: libpopt-1:1.14-alt4 installed
> ...
>
> И всё прекрасно понеслось...
>
> Остаются вопросы: 1) почему так происходит? и 2) почему hasher выдаёт такую
> странную ошибку, по логике он должен бы писать что-то вроде "у вас рабочий
> каталог протух".
>
Присоединяюсь к вопросу. У нас робот иногда тоже такое ловит-(

-- 
С уважением, Борис Савельев

Re: [sisyphus] Потрясающая диагностика в hasher

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 829 bytes --]

On Mon, Jan 26, 2009 at 12:56:42PM +0300, Yury Aliaev wrote:
> Всем доброго времени суток!
> 
> Время от времени при попытке пересобрать 
> пакеты напарываюсь на следующее (словом 
> kosyak у меня всего лишь называется скрипт, 
> вызыающий hsh с нужным рабочим каталогом):
> 
> [mutabor@builder SRPMS]$ kosyak kernel-source-comedi-0.7.76-alt1.src.rpm
> lzop: <stdin>: Compressed data violation
> /.host/cpio: premature end of file
> hsh-initroot: Unpack of 
> /tmp/.private/mutabor/hasher-SS/cache/chroot/chroot.cpio.lzo failed.

Либо файл /tmp/.private/mutabor/hasher-SS/cache/chroot/chroot.cpio.lzo
битый, либо lzop кривой.

В первом случае рекомендую переехать на x86_64 (там tmpfs работает
стабильнее), во втором случае -- пожаловаться upstream.

В остальных случаях вешайте баг на hasher.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] Потрясающая диагностика в hasher

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 525 bytes --]

On Mon, Jan 26, 2009 at 05:38:14PM +0700, REAL wrote:
> Dmitry V. Levin пишет:
> >Либо файл 
> >/tmp/.private/mutabor/hasher-SS/cache/chroot/chroot.cpio.lzo
> >битый, либо lzop кривой.
> >
> >В первом случае рекомендую переехать на 
> >x86_64 (там tmpfs работает
> >стабильнее), во втором случае -- 
> >пожаловаться upstream.
> >
> >В остальных случаях вешайте баг на hasher.
> 
> Иногда каталог с хэшером приходится 
> убивать и переинициализировать,

Зачем?  hasher делает это автоматически.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] Потрясающая диагностика в hasher

[REAL]

Dmitry V. Levin пишет:
> Либо файл /tmp/.private/mutabor/hasher-SS/cache/chroot/chroot.cpio.lzo
> битый, либо lzop кривой.
> 
> В первом случае рекомендую переехать на x86_64 (там tmpfs работает
> стабильнее), во втором случае -- пожаловаться upstream.
> 
> В остальных случаях вешайте баг на hasher.

Иногда каталог с хэшером приходится убивать и переинициализировать, 
думаю, это связано с тем, что apt-репозиторий на машине обновился, а в 
хэшере ещё более старые версии пакетов установлены (учитывая, что 
chroot автоматом переинициализируется, вероятно, это с aptbox связано, 
или как там оно называется...). Так что думаю, что прежде чем вешать 
багу, имеет смысл на месте разобраться, может быть, это вовсе и не бага ;)

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [sisyphus] Потрясающая диагностика в hasher

[REAL]

Dmitry V. Levin пишет:
>> Иногда каталог с хэшером приходится 
>> убивать и переинициализировать,
> 
> Зачем?  hasher делает это автоматически.

Он же только чрут автоматически. Просто я тоже сталкивался с фактом, 
что сборка вываливается. И, насколько позволяет вспомнить мой склероз, 
это всегда было связано с тем, что в репозитории обновлялись пакеты, 
которые должны устанавливаться в хэшер при НАЧАЛЬНОЙ инициализации (а 
не то, что происходит при автоматической переинициализации). Выход был 
- именно убийство всего каталога хэшера. Оно особо и не анноит, 
слишком редкое явление, но робота может в ступор ввести, согласен.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [sisyphus] Потрясающая диагностика в hasher

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

On Mon, Jan 26, 2009 at 05:45:23PM +0700, REAL wrote:
> Dmitry V. Levin пишет:
> >>Иногда каталог с хэшером приходится 
> >>убивать и переинициализировать,
> >
> >Зачем?  hasher делает это автоматически.
> 
> Он же только чрут автоматически. Просто я 
> тоже сталкивался с фактом, что сборка 
> вываливается. И, насколько позволяет 
> вспомнить мой склероз, это всегда было 
> связано с тем, что в репозитории 
> обновлялись пакеты, которые должны 
> устанавливаться в хэшер при НАЧАЛЬНОЙ 
> инициализации (а не то, что происходит 
> при автоматической переинициализации). 

Этого не может быть.  Если бы это было, то это был бы баг.
Аннулирование кеша происходит автоматически и AFAIK безошибочно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [sisyphus] Потрясающая диагностика в hasher

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 565 bytes --]


Twas brillig at 17:58:38 26.01.2009 UTC+07 when root@mmedia2.kemsu.ru did gyre and gimble:

 R> Т.е. всё же более реальнен вариант, что причина - в нестабильности
 R> tmpfs? А это как-то настраивается?

Я бы не отказался от ручки в /sys под названием "стабильность". Заслал
туда 255 - и все баги пропали. Только чтобы при этом компьютер не уходил
в шатдаун :)

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [sisyphus] Потрясающая диагностика в hasher

[REAL]

Dmitry V. Levin пишет:
> Этого не может быть.  Если бы это было, то это был бы баг.
> Аннулирование кеша происходит автоматически и AFAIK безошибочно.

Это ж просто догадки, я не ковырял исходники хэшера. Т.е. всё же более 
реальнен вариант, что причина - в нестабильности tmpfs? А это как-то 
настраивается?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [sisyphus] Потрясающая диагностика в hasher

[Mikhail Gusarov]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]


Twas brillig at 18:06:06 26.01.2009 UTC+07 when root@mmedia2.kemsu.ru did gyre and gimble:

 R> Шутки шутками, но интересует, существует ли в природе механизм,
 R> позволяющий указывать системе, какие данные в tmpfs НЕ подлежат
 R> удалению.

Никакие не подлежат, пока не отмонтируешь.

-- 

[-- Attachment #2: Type: application/pgp-signature, Size: 196 bytes --]

Re: [sisyphus] Потрясающая диагностика в hasher

[REAL]

Mikhail Gusarov пишет:
> Я бы не отказался от ручки в /sys под названием "стабильность". Заслал
> туда 255 - и все баги пропали. Только чтобы при этом компьютер не уходил
> в шатдаун :)

:)

Шутки шутками, но интересует, существует ли в природе механизм, 
позволяющий указывать системе, какие данные в tmpfs НЕ подлежат 
удалению. Или только маркировка времени последнего доступа, и без 
вариантов? Ну тогда действительно остаётся периодической убийство 
каталога хэшера, благо, времени это совсем немного занимает... Но для 
роботов это горькое лекарство ;)


-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [sisyphus] Потрясающая диагностика в hasher

[Yury Aliaev]

Dmitry V. Levin пишет:
>>
>> Время от времени при попытке пересобрать 
>> пакеты напарываюсь на следующее (словом 
>> kosyak у меня всего лишь называется скрипт, 
>> вызыающий hsh с нужным рабочим каталогом):
>>
>> [mutabor@builder SRPMS]$ kosyak kernel-source-comedi-0.7.76-alt1.src.rpm
>> lzop: <stdin>: Compressed data violation
>> /.host/cpio: premature end of file
>> hsh-initroot: Unpack of 
>> /tmp/.private/mutabor/hasher-SS/cache/chroot/chroot.cpio.lzo failed.
> 
> Либо файл /tmp/.private/mutabor/hasher-SS/cache/chroot/chroot.cpio.lzo
> битый, либо lzop кривой.

Спасибо, начинаю вроде понимать. Вспомнил вдогонку, что ловлю такое, 
когда предыдущая сборка завершилась с ошибкой, и hasher за собой, 
соответственно, ничего не подчистил, а следующий запуск производится 
через день или больше.

> 
> В первом случае рекомендую переехать на x86_64 (там tmpfs работает
> стабильнее), во втором случае -- пожаловаться upstream.

Скорее первое.

> 
> В остальных случаях вешайте баг на hasher.
> 

А вот это скорее всего не

Re: [sisyphus] Потрясающая диагностика в hasher

[Alexey Borovskoy]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

* Понедельник 26 января 2009 REAL

> Иногда каталог с хэшером приходится убивать и
> переинициализировать, думаю, это связано с тем, что
> apt-репозиторий на машине обновился, а в хэшере ещё более
> старые версии пакетов установлены (учитывая, что chroot
> автоматом переинициализируется, вероятно, это с aptbox
> связано, или как там оно называется...). Так что думаю, что
> прежде чем вешать багу, имеет смысл на месте разобраться,
> может быть, это вовсе и не бага ;)

Ну на ALS 4.0.1 хэшер так же взрывался.

Пришлось починить.

[alb@alb RPMS.backports]$ ll lzop-1.02-alt0.M40.1.i586.rpm
-rw-r--r-- 1 alb ftpadmin 40763 Ноя 23 16:08 
lzop-1.02-alt0.M40.1.i586.rpm

-- 
Алексей.
GPG key fingerprint
949B BC0E 2C44 7528 4F63  2753 E37A 9E3F 11F3 BDE1

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Потрясающая диагностика в hasher

[Yury Aliaev]

Alexey Borovskoy пишет:
> 
>> Иногда каталог с хэшером приходится убивать и
>> переинициализировать, думаю, это связано с тем, что
>> apt-репозиторий на машине обновился, а в хэшере ещё более
>> старые версии пакетов установлены (учитывая, что chroot
>> автоматом переинициализируется, вероятно, это с aptbox
>> связано, или как там оно называется...). Так что думаю, что
>> прежде чем вешать багу, имеет смысл на месте разобраться,
>> может быть, это вовсе и не бага ;)
> 
> Ну на ALS 4.0.1 хэшер так же взрывался.
> 
> Пришлось починить.
> 
> [alb@alb RPMS.backports]$ ll lzop-1.02-alt0.M40.1.i586.rpm
> -rw-r--r-- 1 alb ftpadmin 40763 Ноя 23 16:08 
> lzop-1.02-alt0.M40.1.i586.rpm
> 

Так что ж, всё же бага lzop? У меня это происходит на Сизифе:

[mutabor@builder SPECS]$ rpmquery lzop
lzop-1.02-alt1

Re: [sisyphus] Потрясающая диагностика в hasher

[Andrew Borodin]

On Mon, Jan 26, 2009 at 02:48:07PM +0300, Yury Aliaev wrote:
> Спасибо, начинаю вроде понимать. Вспомнил вдогонку, что ловлю 
> такое, когда предыдущая сборка завершилась с ошибкой, и hasher 
> за собой, соответственно, ничего не подчистил, а следующий 
> запуск производится через день или больше.

Я всегда использую --lazy-cleanup.

-- 

С уважением,
А. Бородин.

Re: [sisyphus] Потрясающая диагностика в hasher

[REAL]

Mikhail Gusarov пишет:
>  R> Шутки шутками, но интересует, существует ли в природе механизм,
>  R> позволяющий указывать системе, какие данные в tmpfs НЕ подлежат
>  R> удалению.
> Никакие не подлежат, пока не отмонтируешь.

Тогда, отмотав чуть назад:

Dmitry V. Levin пишет:
 > Либо файл /tmp/.private/mutabor/hasher-SS/cache/chroot/chroot.cpio.lzo
 > битый, либо lzop кривой.
 >
 > В первом случае рекомендую переехать на x86_64 (там tmpfs работает
 > стабильнее), во втором случае -- пожаловаться upstream.

интересует, что имеется в виду. Как протестировать tmpfs на 
НЕстабильность, чтобы попробовать поковырять в этом направлении? Я бы, 
  если бы начал без информации извне разбираться, точно на tmpfs стал 
бы думать в последнюю очередь (по крайней мере, ПОСЛЕ хардкорного и 
долгого тестирования памяти на предмет заводского брака)...

PS. Странно, всегда считал архитектуру x86_64 менее надёжной, видимо, 
времена начали меняться?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [sisyphus] Потрясающая диагностика в hasher

[REAL]

Yury Aliaev пишет:
>> Либо файл /tmp/.private/mutabor/hasher-SS/cache/chroot/chroot.cpio.lzo
>> битый, либо lzop кривой.
> Спасибо, начинаю вроде понимать. Вспомнил вдогонку, что ловлю такое, 
> когда предыдущая сборка завершилась с ошибкой, и hasher за собой, 
> соответственно, ничего не подчистил, а следующий запуск производится 
> через день или больше.

Правильно делает, кстати, иначе был бы бесполезен такой замечательный 
инструмент для ловли блох, как hsh-shell.

Но и в этом случае хэшер чрут чистит перед новой сборкой... Думаю, для 
робота можно было бы посоветовать самостоятельное убийство чрута после 
сборки, да посмотреть, будут ли вываливания впредь. Но это если нужна 
именно устойчивость робота к таким инцидентам, и она превышает 
потребность в починке срывающихся сборок.

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [sisyphus] Потрясающая диагностика в hasher

[REAL]

Alexey Borovskoy пишет:
> Ну на ALS 4.0.1 хэшер так же взрывался.
> 
> Пришлось починить.
> 
> [alb@alb RPMS.backports]$ ll lzop-1.02-alt0.M40.1.i586.rpm
> -rw-r--r-- 1 alb ftpadmin 40763 Ноя 23 16:08 
> lzop-1.02-alt0.M40.1.i586.rpm

Подробности можно узнать?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [sisyphus] Потрясающая диагностика в hasher

[Alexey Borovskoy]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

* Вторник 27 января 2009 REAL

> Alexey Borovskoy пишет:
> > Ну на ALS 4.0.1 хэшер так же взрывался.
> >
> > Пришлось починить.
> >
> > [alb@alb RPMS.backports]$ ll lzop-1.02-alt0.M40.1.i586.rpm
> > -rw-r--r-- 1 alb ftpadmin 40763 Ноя 23 16:08
> > lzop-1.02-alt0.M40.1.i586.rpm
>
> Подробности можно узнать?

Точно не помню уже.
Вроде бы падал при распаковке с жалобой на unresolved symbols.

В качестве теста можно взять контейнер с ALS 4.0.1 и распаковать 
в нем что-то, пожатое с помощью lzop. Запаковать получится, а 
распаковать -- нет.

-- 
Алексей.
GPG key fingerprint
949B BC0E 2C44 7528 4F63  2753 E37A 9E3F 11F3 BDE1

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [sisyphus] Потрясающая диагностика в hasher

[Yury Aliaev]

REAL пишет:
> Yury Aliaev пишет:
>>> Либо файл /tmp/.private/mutabor/hasher-SS/cache/chroot/chroot.cpio.lzo
>>> битый, либо lzop кривой.
>> Спасибо, начинаю вроде понимать. Вспомнил вдогонку, что ловлю такое, 
>> когда предыдущая сборка завершилась с ошибкой, и hasher за собой, 
>> соответственно, ничего не подчистил, а следующий запуск производится 
>> через день или больше.
> 
> Правильно делает, кстати, иначе был бы бесполезен такой замечательный 
> инструмент для ловли блох, как hsh-shell.

Да, про этоя в курсе и часто сам использую :)

> 
> Но и в этом случае хэшер чрут чистит перед новой сборкой... Думаю, для 

Увы, дело не в чруте. В моём первом сообщении видно, что принудительный 
запуск hsh-rmchroot не помогает. Нужно чистить весь рабочий каталог, там 
помимо чрута ещё какие-то ошмётки остаются.

> робота можно было бы посоветовать самостоятельное убийство чрута после 
> сборки, да посмотреть, будут ли вываливания впредь. Но это если нужна 
> именно устойчивость робота к таким инцидентам, и она превышает 
> потребность в починке срывающихся сборок.
>