Есть два подтверждённых случая и один вероятный. Обновление p8 -> sisyphus (до 241-alt3): https://lists.altlinux.org/pipermail/devel/2019-March/207479.html Обновление в рамках sisyphus (до 241-alt4): https://lists.altlinux.org/pipermail/sisyphus/2019-April/367833.html Вероятный случай: https://lists.altlinux.org/pipermail/devel/2019-March/207482.html
Да, это очень серьёзная проблема. Но мы пока не умеем её воспроизводить.
Проблема найдена и будет исправлена - рестарт pid 1 надо перенести в файлтриггер.
Дим, может быть нам вообще перенести всю работу с перезапуском приложений из post-скриптов в файлтриггеры ? Или надо что-то делать с порядком обновления пакетов.
(In reply to comment #3) > Дим, может быть нам вообще перенести всю работу с перезапуском приложений из > post-скриптов в файлтриггеры ? Нам нужно минимизировать пребывание служб в неконсистентном состоянии во время обновления. Какие-то можно безболезненно перенести, какие-то могут сильно пострадать от такого переноса. Я не вижу универсального правила. > Или надо что-то делать с порядком обновления пакетов. Например?
(In reply to comment #2) > Проблема найдена и будет исправлена - рестарт pid 1 надо перенести в > файлтриггер. А нужен ли вообще рестарт pid 1? Что-то как-то странно получить перезагрузку даже после всего обновления, штатно. Или по задумке рестарт pid 1 должен без перезагрузки происходить? Если да, то можно, но тогда вопрос следующий - а с чего перезагрузка? Другой баг?
(In reply to comment #5) > > А нужен ли вообще рестарт pid 1? Да, в этом есть некоторый смысл. При обновлении SysVinit тоже происходит pid 1 re-exec, можете проверить по логам. Просто там это обычно происходит без каких-либо шероховатостей.
(В ответ на комментарий №4) > Нам нужно минимизировать пребывание служб в неконсистентном состоянии во время > обновления. С другой стороны, если перезапуск выполняется сразу после обновления пакета службы, неконсистентное состояние может возникнуть позже, если по каким-то причинам другой пакет, используемый службой, обновляется хоть и в этой же транзакции, но позже. Подобная ситуация может сложиться, например, при выносе плагинов в отдельные подпакеты, или из-за особенностей локальной конфигурации службы. Причём такая неконсистентность уже не исправится автоматически, а сохранится либо до ручного перезапуска службы, либо до перезагрузки. В некоторых дистрибутивах в попытках решить проблему обновления дошли даже до https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html (да, в GUI это выглядит именно как оповещение «Перезагрузите компьютер, чтобы установить важные обновления»).
(В ответ на комментарий №4) > (In reply to comment #3) > > Или надо что-то делать с порядком обновления пакетов. > > Например? У нас очерёдность обновления выстраивается как-то так, что в момент перезапуска pid 1 состояние системы не позволяет это сделать корректно. К сожалению, эта ошибка очень тяжело воспроизводится и точно сказать что именно не так с порядком - невозможно. У /sbin/init слишком много зависимостей, много что может пойти не так: $ ldd /sbin/init linux-vdso.so.1 (0x00007fff04025000) libc.so.6 => /lib64/libc.so.6 (0x00007f9adc228000) libsystemd-shared-241.so => /lib/systemd/libsystemd-shared-241.so (0x00007f9adbf9c000) librt.so.1 => /lib64/librt.so.1 (0x00007f9adbf92000) libseccomp.so.2 => /lib64/libseccomp.so.2 (0x00007f9adbf49000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f9adbf1e000) libmount.so.1 => /lib64/libmount.so.1 (0x00007f9adbcc6000) libpam.so.0 => /lib64/libpam.so.0 (0x00007f9adbab5000) libaudit.so.1 => /lib64/libaudit.so.1 (0x00007f9adba8c000) libkmod.so.2 => /lib64/libkmod.so.2 (0x00007f9adba73000) /lib64/ld-linux-x86-64.so.2 (0x00007f9adc58d000) libcap.so.2 => /lib64/libcap.so.2 (0x00007f9adba6b000) libacl.so.1 => /lib64/libacl.so.1 (0x00007f9adba60000) libcryptsetup.so.12 => /lib64/libcryptsetup.so.12 (0x00007f9adba08000) libgcrypt.so.20 => /lib64/libgcrypt.so.20 (0x00007f9adb8e7000) libip4tc.so.0 => /lib64/libip4tc.so.0 (0x00007f9adb8dd000) libidn2.so.0 => /lib64/libidn2.so.0 (0x00007f9adb8be000) liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f9adb892000) liblz4.so.1 => /lib64/liblz4.so.1 (0x00007f9adb874000) libblkid.so.1 => /lib64/libblkid.so.1 (0x00007f9adb626000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9adb603000) libpcre.so.3 => /lib64/libpcre.so.3 (0x00007f9adb5bc000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f9adb5b7000) libz.so.1 => /lib64/libz.so.1 (0x00007f9adb59a000) libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f9adb2cd000) libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f9adb0c4000) libdevmapper.so.1.00 => /lib64/libdevmapper.so.1.00 (0x00007f9adb06a000) libargon2.so.1 => /lib64/libargon2.so.1 (0x00007f9adb061000) libjson-c.so.2 => /lib64/libjson-c.so.2 (0x00007f9adae56000) libgpg-error.so.0 => /lib64/libgpg-error.so.0 (0x00007f9adae34000) libunistring.so.2 => /lib64/libunistring.so.2 (0x00007f9adacb2000) libudev.so.1 => /lib64/libudev.so.1 (0x00007f9adac8a000) libm.so.6 => /lib64/libm.so.6 (0x00007f9adaaf4000)
(В ответ на комментарий №7) > > С другой стороны, если перезапуск выполняется сразу после обновления пакета > службы, неконсистентное состояние может возникнуть позже, если по каким-то > причинам другой пакет, используемый службой, обновляется хоть и в этой же > транзакции, но позже. Подобная ситуация может сложиться, например, при выносе > плагинов в отдельные подпакеты, или из-за особенностей локальной конфигурации > службы. Причём такая неконсистентность уже не исправится автоматически, а > сохранится либо до ручного перезапуска службы, либо до перезагрузки. Я не так давно эту проблему чинил в apache и php - в некоторых случаях порядок обновления пакетов выстраивался так, что основная служба обновлялась раньше модулей и перезапуск сервиса был в момент неконсистентного состояния системы. Перенос рестарта в файлтриггер решил эту проблему.
(In reply to comment #6) > Просто там это обычно происходит без каких-либо шероховатостей. Что-то пишут про "systemctl daemon-reexec". Или как раз это и делалось, но что-то пошло не так?
(In reply to comment #2) > Проблема найдена и будет исправлена - рестарт pid 1 надо перенести в > файлтриггер. Мысль посетила. И что получится? Про reboot при обновлении вообще я высказался уже, что это плохо. Но ещё же и технические детали. Во-первых, могут выполниться не все триггеры, если systemd решит перегрузить ОС, хотя, наверное, можно как-то системдшный триггер последним выполнить. Во-вторых, а как же возможный после триггеров rpm --rebuilddb? Хотя, наверное, там можно сделать паузу, потом проверить, не пошла ли система в перезагрузку. Но как-то всё надёжным не выглядит.
перезапуск pid 1 это не reboot.
(In reply to comment #12) > перезапуск pid 1 это не reboot. Баг вообще-то именно про reboot. Или перезагрузка - просто последствие несвоевременного перезапуска, а в нормальной жизни её не должно было случиться никогда?
(В ответ на комментарий №13) > (In reply to comment #12) > > > перезапуск pid 1 это не reboot. > > Баг вообще-то именно про reboot. Или перезагрузка - просто последствие > несвоевременного перезапуска, а в нормальной жизни её не должно было случиться > никогда? Ну естественно, никто не планировал жёстко перегружать компьютер целиком.
(In reply to comment #14) > Ну естественно, никто не планировал жёстко перегружать компьютер целиком. Что у нас никто не планировал - это я практически не сомневаюсь. :-) Я про сам systemd. Хотелось бы понять, что это именно сбой, а не предусмотренное поведение при перезапуске, пусть и в каких-то очень редких случаях. А то ещё окажется, что они там считают это нормальным.
(In reply to comment #15) > (In reply to comment #14) > > > Ну естественно, никто не планировал жёстко перегружать компьютер целиком. > > Что у нас никто не планировал - это я практически не сомневаюсь. :-) Я про сам > systemd. Хотелось бы понять, что это именно сбой, Это авария во время pid 1 re-exec, у systemd такое иногда бывает. У pid 1 из sysvinit такого не бывает, но он немного попроще. :)
(In reply to comment #7) > (В ответ на комментарий №4) > > Нам нужно минимизировать пребывание служб в неконсистентном состоянии во время > > обновления. > > С другой стороны, если перезапуск выполняется сразу после обновления пакета > службы, неконсистентное состояние может возникнуть позже, если по каким-то > причинам другой пакет, используемый службой, обновляется хоть и в этой же > транзакции, но позже. Подобная ситуация может сложиться, например, при выносе > плагинов в отдельные подпакеты, или из-за особенностей локальной конфигурации > службы. Причём такая неконсистентность уже не исправится автоматически, а > сохранится либо до ручного перезапуска службы, либо до перезагрузки. Мы можем попробовать разделить все службы на 2 категории: - те, которые нормально переносят долгое обновление, перезапуск которых можно отложить на окончание транзакции (хотя тут возникают вопросы с порядком перезапуска), например, pid 1; - те, которые плохо переносят долгое обновление, которые нужно остановить в начале обновления (например, так сделано у нас в postfix) и запустить снова по окончании обновления. Для упорядочивания перезапуска можно сохранять какую-нибудь информацию для файлтриггера в %post пакетов.
(В ответ на комментарий №16) > Это авария во время pid 1 re-exec, у systemd такое иногда бывает. > У pid 1 из sysvinit такого не бывает, но он немного попроще. :) "Ты выглядишь так несовременно рядом со мной" (ц) // подпишусь-ка и я
в p8 это уже исправлено.
(In reply to comment #19) > в p8 это уже исправлено. В смысле re-exec в триггер перенесён?
да
Каков текущий статус этой темы?
В p8 исправление есть, в Sisyphus не знаю.
В Сизифе тоже исправлено.