Как корректно завершить процесс postgresql?

Question

[Анатолий]

Веб-сервер VirtualBox (linux alpine + nginx + php-fpm + postgresql)
В какой то момент веб-интерфейс перестал отвечать, по логам стало ясно, что база данных перестала отвечать, завис процесс postgresql, при этом Load average увеличился в разы.

postmaster.log

2025-05-06 09:34:16.040 MSK [3340] FATAL:  the database system is shutting down
2025-05-06 09:34:31.041 MSK [3519] FATAL:  the database system is shutting down
2025-05-06 09:34:46.041 MSK [3538] FATAL:  the database system is shutting down

top

Mem: 18314384K used, 1688784K free, 201372K shrd, 584188K buff, 6191112K cached
CPU:   0% usr  13% sys   0% nic  85% idle   0% io   1% irq   0% sirq
Load average: 16.02 16.03 16.00 8/389 2466
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
 9805 12923 postgres R     226m   1%   0  12% postgres: bums_www megabase 127.0.0.1(50814)

Во время сбоя в системных логах наблюдались ошибки:

dmesg -T
.............
watchdog: BUG: soft lockup - CPU#0 stuck for 37522s! [postgres:9805]
..............
[Tue May  6 09:13:04 2025] rcu: INFO: rcu_preempt self-detected stall on CPU
rcu: 	0-....: (12112860 ticks this GP) idle=ac6c/1/0x4000000000000000 softirq=74957625/74957676 fqs=6054012
rcu: 	(t=12114827 jiffies g=102999477 q=15248875 ncpus=8)
.........

ps aux

9805 postgres 11h24 postgres: bums_www megabase 127.0.0.1(50814)

Попытка перезапустить postgresql или остановить, завершается ошибкой failed:

sudo /etc/init.d/postgresql restart
 * Stopping PostgreSQL 16 (this can take up to 15 seconds) ...
...............
 * start-stop-daemon: 1 process refused to stop
 * Failed to stop PostgreSQL 16

Команда kill 9805 не завершает процесс

В конечном итоге помог перезапуск виртуальной машины, но хотелось бы понять причину и правильный способ решения

Не уверен, что как то связано, но после перезапуска машины, в системных логах наблюдаются ошибки:

[drm] *ERROR* vmwgfx seems to be running on an unsupported hypervisor.
[drm] *ERROR* This configuration is likely broken.

Answer 1

[Melkij]

Отсутствие реакции на SIGTERM при продолжающемся потреблении CPU это примечательно. Но без -dbgsym и GDB ничего определённого выяснить фактически не удастся. Суть - как-то попали в какую-то ветвь кода, которая не считалась что может занимать продолжительное время и вызов обработчика сигналов CHECK_FOR_INTERRUPTS там не был предусмотрен. Из вариантов навскидку где возможно в 16.х наступить - dblink или fdw, create index using hash. Традиционно, ещё могут быть index scan по gin или gist, не в первый раз находятся у них такие грабли.
Как минимум, удостовериться, что используется свежая минорная версия. Завтра 16.9 выходит.

Ну, это из предположения что весьма подозрительный watchdog: BUG: soft lockup тут ни при чём. Что это такое я вряд ли подскажу. Выглядит нехорошо.

Такс, это всё про оставшийся процесс.
Про сам the database system is shutting down
При crash recovery делается immediate stop, все backend которые не завершаться за 5 секунд получат SIGKILL. Который, естественно, проигнорировать уже не могут, потому что процессу про SIGKILL никто даже и не скажет, его просто снимет ядро ОС.
Значит, перед всеми the database system is shutting down был received smart shutdown request или received fast shutdown request, который кто-то скомандовал явным образом. Оба режима штатного выключения не делают SIGKILL, а именно дождутся корректного завершения процесса. В случае с багом, когда процесс не отреагировал на SIGTERM, ну, вечно ждать и будет. Других вариантов кроме SIGKILL тут нет.

Если логи ещё сохранились на дату shutdown request - то смотреть что там делали с системой, что кто-то скомандовал stop или restart базе. Если не вмешательство администратора, то может быть какой-то аналог unattended-upgrades?