Bug 36579

Да, это очень серьёзная проблема. Но мы пока не умеем её воспроизводить.

Проблема найдена и будет исправлена - рестарт 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 не знаю.

В Сизифе тоже исправлено.