36579 2019-04-10 09:15:02 +0300 В момент обновления пакета systemd иногда происходит перезагрузка системы 2024-05-19 18:07:06 +0300 1 1 4 Development Sisyphus systemd unstable all Linux CLOSED FIXED P3 blocker --- 34231 1 asy shaba aen arseny iv junior ldv mike rider shaba vsu yukh qa-sisyphus oldest_to_newest 180701 0 asy 2019-04-10 09:15:02 +0300 Есть два подтверждённых случая и один вероятный. Обновление 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 180702 1 rider 2019-04-10 09:31:34 +0300 Да, это очень серьёзная проблема. Но мы пока не умеем её воспроизводить. 180728 2 rider 2019-04-10 17:30:14 +0300 Проблема найдена и будет исправлена - рестарт pid 1 надо перенести в файлтриггер. 180729 3 rider 2019-04-10 17:31:57 +0300 Дим, может быть нам вообще перенести всю работу с перезапуском приложений из post-скриптов в файлтриггеры ? Или надо что-то делать с порядком обновления пакетов. 180730 4 ldv 2019-04-10 17:44:30 +0300 (In reply to comment #3) > Дим, может быть нам вообще перенести всю работу с перезапуском приложений из > post-скриптов в файлтриггеры ? Нам нужно минимизировать пребывание служб в неконсистентном состоянии во время обновления. Какие-то можно безболезненно перенести, какие-то могут сильно пострадать от такого переноса. Я не вижу универсального правила. > Или надо что-то делать с порядком обновления пакетов. Например? 180731 5 asy 2019-04-10 17:50:24 +0300 (In reply to comment #2) > Проблема найдена и будет исправлена - рестарт pid 1 надо перенести в > файлтриггер. А нужен ли вообще рестарт pid 1? Что-то как-то странно получить перезагрузку даже после всего обновления, штатно. Или по задумке рестарт pid 1 должен без перезагрузки происходить? Если да, то можно, но тогда вопрос следующий - а с чего перезагрузка? Другой баг? 180732 6 ldv 2019-04-10 17:56:09 +0300 (In reply to comment #5) > > А нужен ли вообще рестарт pid 1? Да, в этом есть некоторый смысл. При обновлении SysVinit тоже происходит pid 1 re-exec, можете проверить по логам. Просто там это обычно происходит без каких-либо шероховатостей. 180734 7 vsu 2019-04-10 18:36:39 +0300 (В ответ на комментарий №4) > Нам нужно минимизировать пребывание служб в неконсистентном состоянии во время > обновления. С другой стороны, если перезапуск выполняется сразу после обновления пакета службы, неконсистентное состояние может возникнуть позже, если по каким-то причинам другой пакет, используемый службой, обновляется хоть и в этой же транзакции, но позже. Подобная ситуация может сложиться, например, при выносе плагинов в отдельные подпакеты, или из-за особенностей локальной конфигурации службы. Причём такая неконсистентность уже не исправится автоматически, а сохранится либо до ручного перезапуска службы, либо до перезагрузки. В некоторых дистрибутивах в попытках решить проблему обновления дошли даже до https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html (да, в GUI это выглядит именно как оповещение «Перезагрузите компьютер, чтобы установить важные обновления»). 180735 8 rider 2019-04-10 18:44:00 +0300 (В ответ на комментарий №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) 180736 9 rider 2019-04-10 18:49:18 +0300 (В ответ на комментарий №7) > > С другой стороны, если перезапуск выполняется сразу после обновления пакета > службы, неконсистентное состояние может возникнуть позже, если по каким-то > причинам другой пакет, используемый службой, обновляется хоть и в этой же > транзакции, но позже. Подобная ситуация может сложиться, например, при выносе > плагинов в отдельные подпакеты, или из-за особенностей локальной конфигурации > службы. Причём такая неконсистентность уже не исправится автоматически, а > сохранится либо до ручного перезапуска службы, либо до перезагрузки. Я не так давно эту проблему чинил в apache и php - в некоторых случаях порядок обновления пакетов выстраивался так, что основная служба обновлялась раньше модулей и перезапуск сервиса был в момент неконсистентного состояния системы. Перенос рестарта в файлтриггер решил эту проблему. 180737 10 asy 2019-04-10 20:01:43 +0300 (In reply to comment #6) > Просто там это обычно происходит без каких-либо шероховатостей. Что-то пишут про "systemctl daemon-reexec". Или как раз это и делалось, но что-то пошло не так? 180738 11 asy 2019-04-10 20:18:21 +0300 (In reply to comment #2) > Проблема найдена и будет исправлена - рестарт pid 1 надо перенести в > файлтриггер. Мысль посетила. И что получится? Про reboot при обновлении вообще я высказался уже, что это плохо. Но ещё же и технические детали. Во-первых, могут выполниться не все триггеры, если systemd решит перегрузить ОС, хотя, наверное, можно как-то системдшный триггер последним выполнить. Во-вторых, а как же возможный после триггеров rpm --rebuilddb? Хотя, наверное, там можно сделать паузу, потом проверить, не пошла ли система в перезагрузку. Но как-то всё надёжным не выглядит. 180740 12 rider 2019-04-10 20:37:19 +0300 перезапуск pid 1 это не reboot. 180741 13 asy 2019-04-10 20:43:48 +0300 (In reply to comment #12) > перезапуск pid 1 это не reboot. Баг вообще-то именно про reboot. Или перезагрузка - просто последствие несвоевременного перезапуска, а в нормальной жизни её не должно было случиться никогда? 180745 14 shaba 2019-04-10 21:32:26 +0300 (В ответ на комментарий №13) > (In reply to comment #12) > > > перезапуск pid 1 это не reboot. > > Баг вообще-то именно про reboot. Или перезагрузка - просто последствие > несвоевременного перезапуска, а в нормальной жизни её не должно было случиться > никогда? Ну естественно, никто не планировал жёстко перегружать компьютер целиком. 180749 15 asy 2019-04-10 22:22:18 +0300 (In reply to comment #14) > Ну естественно, никто не планировал жёстко перегружать компьютер целиком. Что у нас никто не планировал - это я практически не сомневаюсь. :-) Я про сам systemd. Хотелось бы понять, что это именно сбой, а не предусмотренное поведение при перезапуске, пусть и в каких-то очень редких случаях. А то ещё окажется, что они там считают это нормальным. 180750 16 ldv 2019-04-10 22:25:53 +0300 (In reply to comment #15) > (In reply to comment #14) > > > Ну естественно, никто не планировал жёстко перегружать компьютер целиком. > > Что у нас никто не планировал - это я практически не сомневаюсь. :-) Я про сам > systemd. Хотелось бы понять, что это именно сбой, Это авария во время pid 1 re-exec, у systemd такое иногда бывает. У pid 1 из sysvinit такого не бывает, но он немного попроще. :) 180751 17 ldv 2019-04-10 22:33:05 +0300 (In reply to comment #7) > (В ответ на комментарий №4) > > Нам нужно минимизировать пребывание служб в неконсистентном состоянии во время > > обновления. > > С другой стороны, если перезапуск выполняется сразу после обновления пакета > службы, неконсистентное состояние может возникнуть позже, если по каким-то > причинам другой пакет, используемый службой, обновляется хоть и в этой же > транзакции, но позже. Подобная ситуация может сложиться, например, при выносе > плагинов в отдельные подпакеты, или из-за особенностей локальной конфигурации > службы. Причём такая неконсистентность уже не исправится автоматически, а > сохранится либо до ручного перезапуска службы, либо до перезагрузки. Мы можем попробовать разделить все службы на 2 категории: - те, которые нормально переносят долгое обновление, перезапуск которых можно отложить на окончание транзакции (хотя тут возникают вопросы с порядком перезапуска), например, pid 1; - те, которые плохо переносят долгое обновление, которые нужно остановить в начале обновления (например, так сделано у нас в postfix) и запустить снова по окончании обновления. Для упорядочивания перезапуска можно сохранять какую-нибудь информацию для файлтриггера в %post пакетов. 180759 18 mike 2019-04-11 13:31:34 +0300 (В ответ на комментарий №16) > Это авария во время pid 1 re-exec, у systemd такое иногда бывает. > У pid 1 из sysvinit такого не бывает, но он немного попроще. :) "Ты выглядишь так несовременно рядом со мной" (ц) // подпишусь-ка и я 181017 19 rider 2019-04-19 15:21:58 +0300 в p8 это уже исправлено. 181023 20 asy 2019-04-19 16:54:49 +0300 (In reply to comment #19) > в p8 это уже исправлено. В смысле re-exec в триггер перенесён? 181024 21 rider 2019-04-19 16:55:24 +0300 да 182528 22 ldv 2019-06-18 16:18:21 +0300 Каков текущий статус этой темы? 182529 23 rider 2019-06-18 16:19:24 +0300 В p8 исправление есть, в Sisyphus не знаю. 182531 24 shaba 2019-06-18 16:32:13 +0300 В Сизифе тоже исправлено.