Bug 36579 - В момент обновления пакета systemd иногда происходит перезагрузка системы
Summary: В момент обновления пакета systemd иногда происходит перезагрузка системы
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: systemd (show other bugs)
Version: unstable
Hardware: all Linux
: P3 blocker
Assignee: Alexey Shabalin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 34231
  Show dependency tree
 
Reported: 2019-04-10 09:15 MSK by Sergey Y. Afonin
Modified: 2019-06-18 16:32 MSK (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Y. Afonin 2019-04-10 09:15:02 MSK
Есть два подтверждённых случая и один вероятный.

Обновление 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
Comment 1 Anton Farygin 2019-04-10 09:31:34 MSK
Да, это очень серьёзная проблема. Но мы пока не умеем её воспроизводить.
Comment 2 Anton Farygin 2019-04-10 17:30:14 MSK
Проблема найдена и будет исправлена - рестарт pid 1 надо перенести в файлтриггер.
Comment 3 Anton Farygin 2019-04-10 17:31:57 MSK
Дим, может быть нам вообще перенести всю работу с перезапуском приложений из post-скриптов в файлтриггеры ?

Или надо что-то делать с порядком обновления пакетов.
Comment 4 Dmitry V. Levin 2019-04-10 17:44:30 MSK
(In reply to comment #3)
> Дим, может быть нам вообще перенести всю работу с перезапуском приложений из
> post-скриптов в файлтриггеры ?

Нам нужно минимизировать пребывание служб в неконсистентном состоянии во время обновления.

Какие-то можно безболезненно перенести, какие-то могут сильно пострадать от такого переноса.

Я не вижу универсального правила.

> Или надо что-то делать с порядком обновления пакетов.

Например?
Comment 5 Sergey Y. Afonin 2019-04-10 17:50:24 MSK
(In reply to comment #2)

> Проблема найдена и будет исправлена - рестарт pid 1 надо перенести в
> файлтриггер.

А нужен ли вообще рестарт pid 1? Что-то как-то странно получить перезагрузку даже после всего обновления, штатно. Или по задумке рестарт pid 1 должен без перезагрузки происходить? Если да, то можно, но тогда вопрос следующий - а с чего перезагрузка? Другой баг?
Comment 6 Dmitry V. Levin 2019-04-10 17:56:09 MSK
(In reply to comment #5)
> 
> А нужен ли вообще рестарт pid 1?

Да, в этом есть некоторый смысл.
При обновлении SysVinit тоже происходит pid 1 re-exec, можете проверить по логам.
Просто там это обычно происходит без каких-либо шероховатостей.
Comment 7 Sergey Vlasov 2019-04-10 18:36:39 MSK
(В ответ на комментарий №4)
> Нам нужно минимизировать пребывание служб в неконсистентном состоянии во время
> обновления.

С другой стороны, если перезапуск выполняется сразу после обновления пакета службы, неконсистентное состояние может возникнуть позже, если по каким-то причинам другой пакет, используемый службой, обновляется хоть и в этой же транзакции, но позже. Подобная ситуация может сложиться, например, при выносе плагинов в отдельные подпакеты, или из-за особенностей локальной конфигурации службы. Причём такая неконсистентность уже не исправится автоматически, а сохранится либо до ручного перезапуска службы, либо до перезагрузки.

В некоторых дистрибутивах в попытках решить проблему обновления дошли даже до https://www.freedesktop.org/software/systemd/man/systemd.offline-updates.html (да, в GUI это выглядит именно как оповещение «Перезагрузите компьютер, чтобы установить важные обновления»).
Comment 8 Anton Farygin 2019-04-10 18:44:00 MSK
(В ответ на комментарий №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)
Comment 9 Anton Farygin 2019-04-10 18:49:18 MSK
(В ответ на комментарий №7)
> 
> С другой стороны, если перезапуск выполняется сразу после обновления пакета
> службы, неконсистентное состояние может возникнуть позже, если по каким-то
> причинам другой пакет, используемый службой, обновляется хоть и в этой же
> транзакции, но позже. Подобная ситуация может сложиться, например, при выносе
> плагинов в отдельные подпакеты, или из-за особенностей локальной конфигурации
> службы. Причём такая неконсистентность уже не исправится автоматически, а
> сохранится либо до ручного перезапуска службы, либо до перезагрузки.

Я не так давно эту проблему чинил в apache и php - в некоторых случаях порядок обновления пакетов выстраивался так, что основная служба обновлялась раньше модулей и перезапуск сервиса был в момент неконсистентного состояния системы.

Перенос рестарта в файлтриггер решил эту проблему.
Comment 10 Sergey Y. Afonin 2019-04-10 20:01:43 MSK
(In reply to comment #6)

> Просто там это обычно происходит без каких-либо шероховатостей.

Что-то пишут про "systemctl daemon-reexec". Или как раз это и делалось, но что-то пошло не так?
Comment 11 Sergey Y. Afonin 2019-04-10 20:18:21 MSK
(In reply to comment #2)

> Проблема найдена и будет исправлена - рестарт pid 1 надо перенести в
> файлтриггер.

Мысль посетила. И что получится? Про reboot при обновлении вообще я высказался уже, что это плохо. Но ещё же и технические детали. Во-первых, могут выполниться не все триггеры, если systemd решит перегрузить ОС, хотя, наверное, можно как-то системдшный триггер последним выполнить. Во-вторых, а как же возможный после триггеров rpm --rebuilddb? Хотя, наверное, там можно сделать паузу, потом проверить, не пошла ли система в перезагрузку. Но как-то всё надёжным не выглядит.
Comment 12 Anton Farygin 2019-04-10 20:37:19 MSK
перезапуск pid 1 это не reboot.
Comment 13 Sergey Y. Afonin 2019-04-10 20:43:48 MSK
(In reply to comment #12)

> перезапуск pid 1 это не reboot.

Баг вообще-то именно про reboot. Или перезагрузка - просто последствие несвоевременного перезапуска, а в нормальной жизни её не должно было случиться никогда?
Comment 14 Alexey Shabalin 2019-04-10 21:32:26 MSK
(В ответ на комментарий №13)
> (In reply to comment #12)
> 
> > перезапуск pid 1 это не reboot.
> 
> Баг вообще-то именно про reboot. Или перезагрузка - просто последствие
> несвоевременного перезапуска, а в нормальной жизни её не должно было случиться
> никогда?

Ну естественно, никто не планировал жёстко перегружать компьютер целиком.
Comment 15 Sergey Y. Afonin 2019-04-10 22:22:18 MSK
(In reply to comment #14)

> Ну естественно, никто не планировал жёстко перегружать компьютер целиком.

Что у нас никто не планировал - это я практически не сомневаюсь. :-) Я про сам systemd. Хотелось бы понять, что это именно сбой, а не предусмотренное поведение при перезапуске, пусть и в каких-то очень редких случаях. А то ещё окажется, что они там считают это нормальным.
Comment 16 Dmitry V. Levin 2019-04-10 22:25:53 MSK
(In reply to comment #15)
> (In reply to comment #14)
> 
> > Ну естественно, никто не планировал жёстко перегружать компьютер целиком.
> 
> Что у нас никто не планировал - это я практически не сомневаюсь. :-) Я про сам
> systemd. Хотелось бы понять, что это именно сбой,

Это авария во время pid 1 re-exec, у systemd такое иногда бывает.
У pid 1 из sysvinit такого не бывает, но он немного попроще. :)
Comment 17 Dmitry V. Levin 2019-04-10 22:33:05 MSK
(In reply to comment #7)
> (В ответ на комментарий №4)
> > Нам нужно минимизировать пребывание служб в неконсистентном состоянии во время
> > обновления.
> 
> С другой стороны, если перезапуск выполняется сразу после обновления пакета
> службы, неконсистентное состояние может возникнуть позже, если по каким-то
> причинам другой пакет, используемый службой, обновляется хоть и в этой же
> транзакции, но позже. Подобная ситуация может сложиться, например, при выносе
> плагинов в отдельные подпакеты, или из-за особенностей локальной конфигурации
> службы. Причём такая неконсистентность уже не исправится автоматически, а
> сохранится либо до ручного перезапуска службы, либо до перезагрузки.

Мы можем попробовать разделить все службы на 2 категории:
- те, которые нормально переносят долгое обновление, перезапуск которых можно отложить на окончание транзакции (хотя тут возникают вопросы с порядком перезапуска), например, pid 1;
- те, которые плохо переносят долгое обновление, которые нужно остановить в начале обновления (например, так сделано у нас в postfix) и запустить снова по окончании обновления.

Для упорядочивания перезапуска можно сохранять какую-нибудь информацию для файлтриггера в %post пакетов.
Comment 18 Michael Shigorin 2019-04-11 13:31:34 MSK
(В ответ на комментарий №16)
> Это авария во время pid 1 re-exec, у systemd такое иногда бывает.
> У pid 1 из sysvinit такого не бывает, но он немного попроще. :)
"Ты выглядишь так несовременно рядом со мной" (ц)

// подпишусь-ка и я
Comment 19 Anton Farygin 2019-04-19 15:21:58 MSK
в p8 это уже исправлено.
Comment 20 Sergey Y. Afonin 2019-04-19 16:54:49 MSK
(In reply to comment #19)

> в p8 это уже исправлено.

В смысле re-exec в триггер перенесён?
Comment 21 Anton Farygin 2019-04-19 16:55:24 MSK
да
Comment 22 Dmitry V. Levin 2019-06-18 16:18:21 MSK
Каков текущий статус этой темы?
Comment 23 Anton Farygin 2019-06-18 16:19:24 MSK
В p8 исправление есть, в Sisyphus не знаю.
Comment 24 Alexey Shabalin 2019-06-18 16:32:13 MSK
В Сизифе тоже исправлено.