Summary: | мусор в консоли | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Aleksandr Blokhin <sass> |
Component: | service | Assignee: | placeholder <placeholder> |
Status: | CLOSED WONTFIX | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P2 | CC: | boyarsh, cas, glebfm, ldv, legion, placeholder, sbolshakov, vvk |
Version: | unstable | ||
Hardware: | all | ||
OS: | Linux |
Description
Aleksandr Blokhin
2006-02-18 03:15:02 MSK
/sbin/initlog упал? Почему? Хороший вопрос. Вот и мне хотелось бы знать кто упал и почему. Это уже довольно давно наблюдается. Месяца два наверное. Написать было некогда. У меня та же самая беда. Расскажите, в каком месте запускается этот initlog и куда он пытается писать - может я попробую поковырять это сам. На всякий случай, история жизни этой системы: 1) Поставили древнюю бету Компакта 2) Удалили все, что было возможно 3) Обновили до Сизифа 4) Перетянули на RAID1/LVM2 5) Проблема начала появляться эпизодически, но я ее связал с тем, что сильно изуродовал rc.sysinit - как потом выяснилось зря 6) Обновили еще раз и словили проблемы с правами на /lib (об этом я недавно писал), а текущая проблема стала воспроизводиться регулярно 7) После вчерашнего обновления и отката на стандартный rc.sysinit проблема не решилась Еще вопрос: а почему решили, что виноват initlog? Вот кусок кода, в окрестностях которого проблема: # Log that something succeeded success() { if [ -z "$IN_INITLOG" ]; then initlog $INITLOG_ARGS -n $0 -s "$1" -e 1 else local opipe opipe="$(trap -p SIGPIPE)" trap '' SIGPIPE echo "$INITLOG_ARGS -n $0 -s \"$1\" -e 1" >&21 $opipe fi echo_success return 0 } Т.е. если переменная IN_INITLOG пуста, производится запись в некий дескриптор 12 (кто это? почему так жестко в коде прошили? может переменную хотя бы стоило завести, чтоб понятно было что это такое?) Далее видим: # Remount the root filesystem read-write splash_update remount 2 action "Remounting root filesystem in read/write mode:" mount -n -o remount,rw / # The root filesystem is now read-write, so we can now log via syslog() directly [ -z "$IN_INITLOG" ] || IN_INITLOG= Если обнулить IN_INITLOG в самом начале, то и ругательств никаких не будет. Но ведь в IN_INITLOG=yes, наверное, есть какой-то смысл? Какой? То, что падает initlog, очевидно. То, что он не должен падать, тоже очевидно. Неясно, почему он падает. Может, устройство какое-то во время работы исчезает? У меня это происходит на начальном этапе загрузки системы до загрузки сервисов. Прошу прощения - соврал! Предыдущий постинг прощу считать недействительным! Алексей, ты это, кажется, тоже умеешь воспроизводить? *** Bug 8870 has been marked as a duplicate of this bug. *** (In reply to comment #9) > Алексей, ты это, кажется, тоже умеешь воспроизводить? Да. Я делал образ на котором эта ошибка воспроизводилась на 100% ASSIGNED? (In reply to comment #11) > (In reply to comment #9) > > Алексей, ты это, кажется, тоже умеешь воспроизводить? > > Да. Я делал образ на котором эта ошибка воспроизводилась на 100% Профиль сохранился? Посмотри на дату моего поста :) ... разумеется нет. Это из прошлой жизни, когда я делал Серверные исошки. Можно попробовать исошку из среза за ту дату и попробовать воспроизвести. Попроси спецов по выпечке дистров сделать это. У меня воспроизводилось довольно регулярно. Кто умеет воспроизводить этот баг? я такого не видел. Невозможно воспроизвести, закрываю как WONTFIX. При необходимости откройте. |