Прошу собрать.
Проблема с racket, похоже, плавающая. Один день оно не пересобирается, затем опять собирается: https://lists.altlinux.org/pipermail/sisyphus-cybertalk/2018-December/105191.html https://lists.altlinux.org/pipermail/sisyphus-cybertalk/2018-December/105199.html Аналогичное поведение я замечал и раньше. Вот, например, такое же повторялось в конце ноября: https://lists.altlinux.org/pipermail/sisyphus-cybertalk/2018-November/105140.html https://lists.altlinux.org/pipermail/sisyphus-cybertalk/2018-November/105148.html Локально мне пока что не удавалось воспроизвести проблему. Я собираюсь обновить версию, но нет гарантии, что данная плавающая проблема будет решена таким образом.
Это уж точно какая-то проблема на сборочнице.
(In reply to comment #2) > Это уж точно какая-то проблема на сборочнице. Не похоже. Судя по логу, raco setup иногда просто зацикливается. > 7885.91user 595.28system 39:38.63elapsed 356%CPU (0avgtext+0avgdata 4378412maxresident)k Причём зацикливается в userspace.
(В ответ на комментарий №3) > (In reply to comment #2) > > Это уж точно какая-то проблема на сборочнице. > > Не похоже. Судя по логу, raco setup иногда просто зацикливается. > > > 7885.91user 595.28system 39:38.63elapsed 356%CPU (0avgtext+0avgdata 4378412maxresident)k > > Причём зацикливается в userspace. Он не зацикливается, он может долго работать в секции %install, но локально он ни разу не вис у меня, всегда через некоторое время он успешно завершал свою работу. Похоже, сборочница иногда зря его прибивает, и делает это на основе каких-то неизвестных факторов.
(In reply to comment #4) > (В ответ на комментарий №3) > > (In reply to comment #2) > > > Это уж точно какая-то проблема на сборочнице. > > > > Не похоже. Судя по логу, raco setup иногда просто зацикливается. > > > > > 7885.91user 595.28system 39:38.63elapsed 356%CPU (0avgtext+0avgdata 4378412maxresident)k > > > > Причём зацикливается в userspace. > > Он не зацикливается, он может долго работать в секции %install, но локально он > ни разу не вис у меня, всегда через некоторое время он успешно завершал свою > работу. Похоже, сборочница иногда зря его прибивает, и делает это на основе > каких-то неизвестных факторов. Судя по логу, оно само умирает: make[1]: *** [Makefile:178: install-3m] CPU time limit exceeded В /etc/hasher-priv/system написано: rlimit_soft_cpu=7200 rlimit_hard_cpu=7260 Другими словами, каждому процессу выделено до 2 часов CPU time. Это очень много.
(В ответ на комментарий №5) > Судя по логу, оно само умирает: > make[1]: *** [Makefile:178: install-3m] CPU time limit exceeded > > В /etc/hasher-priv/system написано: > rlimit_soft_cpu=7200 > rlimit_hard_cpu=7260 > > Другими словами, каждому процессу выделено до 2 часов CPU time. > Это очень много. Судя по логу, его убивают лимиты, а вовсе не само оно умирает. Это не противоречит тому, что иногда из-за некоторых факторов, предположительно внешних, этих лимитов для установки ему хватает, а иногда - нет.
Дим, а может ли быть такая ситуация, что по каким-то внешним причинам (загруженность машины, overcommit или ещё что-то) процесс начинает долго висеть ? У меня тоже был какой-то пакет, который умирал по CPU Time, но как-то оно само рассосалось.
(In reply to comment #7) > Дим, а может ли быть такая ситуация, что по каким-то внешним причинам > (загруженность машины, overcommit или ещё что-то) процесс начинает долго висеть > ? Висение процесса не влияет на то время, которое ограничивает RLIMIT_CPU, если, конечно, ядро не спятило. > У меня тоже был какой-то пакет, который умирал по CPU Time, но как-то оно само > рассосалось. Это, наверное, был wlimit_time_elapsed или wlimit_time_idle.
(In reply to comment #6) > (В ответ на комментарий №5) > > Судя по логу, оно само умирает: > > make[1]: *** [Makefile:178: install-3m] CPU time limit exceeded > > > > В /etc/hasher-priv/system написано: > > rlimit_soft_cpu=7200 > > rlimit_hard_cpu=7260 > > > > Другими словами, каждому процессу выделено до 2 часов CPU time. > > Это очень много. > > Судя по логу, его убивают лимиты, а вовсе не само оно умирает. > > Это не противоречит тому, что иногда из-за некоторых факторов, предположительно > внешних, этих лимитов для установки ему хватает, а иногда - нет. Я могу попробовать увеличить этот лимит (который призван ловить зацикливания) раза в два, тогда мы сможем понаблюдать, как это повлияет на результат.
Да, я тоже хотел тебе предложить. Я посмотрел на разницу между успешной и ошибочной сборкой racket и вижу, что в случае успеха он просто успевает ещё выполнить 56 операций по сборке. на fail дополнительных повторных процессов raco setup , отсутствующих на success - я не вижу.
2ldv: не увеличил ?
(In reply to comment #11) > 2ldv: не увеличил ? Увеличил с двух часов до трёх. Кажется, не помогло. Видимо, всё-таки зацикливается с некоторой вероятностью.
racket-6.12-alt1 -> sisyphus: Mon Dec 10 2018 Aleksei Nikiforov <darktemplar@altlinux> 6.12-alt1 - Updated to upstream version 6.12 (Closes: #35721)
Спасибо!
*** Bug 36203 has been marked as a duplicate of this bug. ***
Сейчас там наблюдается hasher-priv: master: idle time limit (3600 seconds) exceeded hsh-rebuild: rebuild of `racket-6.12-alt1.src.rpm' failed. Насколько я понимаю, сборка racket очень чувствительна к загруженности сборочного сервера.
*** Bug 40313 has been marked as a duplicate of this bug. ***
