| 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, vt, 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. При необходимости откройте. |