[BUG] postgres sigkill

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Prostredie: Claude Code on the web
Model: (ktorý CCW používa)
Dátum meraní: 15.8.2026

Postgres v remote execution prostredí (Claude Code on the web) je opakovane
zabíjaný zvonku.

MERANIE (z logu jedného kontajnera, PostgreSQL 16 spustený priamo, port 5433):
87 štartov
86 štartov po nekorektnom ukončení ("database system was not properly
shut down")
0 záznamov o riadnom vypnutí ("received smart/fast shutdown request")

Postgres pri SIGTERM vždy zaloguje shutdown request. Nula takých riadkov pri
86 nekorektných štartoch znamená SIGKILL — proces je zabitý bez možnosti
zareagovať.

VYLÚČENÉ: pamäť (15 GB celkovo, ~14 GB voľných v čase pádu, žiadny OOM
v logu), disk (27 GB voľných, 29 % využitie), Postgres samotný
(žiadny PANIC ani FATAL, crash recovery vždy prebehne čisto).

DÔSLEDOK, KTORÝ SA NEDÁ VRÁTIŤ: zabitý testovací beh nestihne upratovacie
fixtúry a nechá po sebe riadky v tabuľkách, ktoré sú append-only na úrovni
databázového triggera. Nazbieralo sa 10 526 + 1 211 + 2 550 riadkov až po
rok 9999, prideľovač testovacích období minul kalendár a 69 testov padlo na
"ValueError: year 10000 is out of range" — bez súvislosti s meneným kódom.
Upratať sa to dalo len dočasným vypnutím triggerov cez superuser kanál.
Každý zabitý beh teda skracuje životnosť testovacej databázy.

OTÁZKA: existuje v prostredí watchdog alebo limit, ktorý zabíja dlho bežiace
procesy na pozadí? Docker v kontajneri nebeží, preto je testovací Postgres
spustený priamo, nie cez compose.

What Should Happen?

Prostredie:
OS Ubuntu 24.04.4 LTS (Noble Numbat)
kernel 6.18.5-fc-v20 (Firecracker microVM, PID 1 = process_api,
žiadny systemd ani iný service manager)
PostgreSQL 16.13 (Ubuntu 16.13-0ubuntu0.24.04.1), spustený cez pg_ctl
priamo, nie ako služba (Docker v kontajneri nebeží)
shell /bin/bash
Claude Code 2.1.233
používateľ root (uid=0)

Príznak: testovací Postgres opakovane zmizne uprostred behu testov. Dá sa
naštartovať znova, dáta prežijú (crash recovery je čistá).

MERANIE z jedného logu (/tmp/pg.log, databáza existuje od 6. 8.):
87 štartov
86 štartov po nekorektnom ukončení ("database system was not properly
shut down")
0 záznamov o riadnom vypnutí ("received smart/fast shutdown request")

Postgres pri SIGTERM vždy zaloguje shutdown request. Nula takých riadkov pri
86 nekorektných štartoch znamená, že sa proces nikdy nemohol ukončiť riadne.

PRÍČINA (odvodená z meraní, nie odhad): reštartuje sa celý microVM.

• uptime VM 7 minút, hoci session beží hodiny
• posledný záznam v logu Postgresu 21:32 UTC, aktuálny čas 23:13 UTC —

medzi tým v logu nič, teda VM medzitým nabootoval nanovo

• disk pritom prežíva (dátový adresár z 6. 8.)
• PID 1 je process_api, nie init, takže manuálne spustenú databázu nemá

kto po štarte VM obnoviť

VYLÚČENÉ: pamäť (15 GB celkovo, ~14 GB voľných v čase pádu; dmesg dostupný,
354 riadkov, 0 záznamov o OOM), disk (27 GB voľných, 29 % využitie),
Postgres samotný (žiadny PANIC ani FATAL pred ukončením).

DÔSLEDOK, KTORÝ SA NEDÁ VRÁTIŤ: prerušený testovací beh nestihne upratovacie
fixtúry a nechá po sebe riadky v tabuľkách, ktoré sú append-only na úrovni
databázového triggera. Nazbieralo sa 10 526 + 1 211 + 2 550 riadkov až po rok
9999, prideľovač testovacích období minul kalendár a 69 testov padlo na
"ValueError: year 10000 is out of range" — bez súvislosti s meneným kódom.
Upratať sa to dalo len dočasným vypnutím triggerov cez superuser kanál.
Každý prerušený beh teda skracuje životnosť testovacej databázy.

OTÁZKY:

1. Je reštart microVM očakávané správanie (idle suspend / reclaim)? Ak áno,

dá sa to niekde nastaviť alebo predĺžiť?

1. Existuje podporovaný spôsob, ako v tomto prostredí prevádzkovať testovaciu

databázu tak, aby prežila reštart VM — alebo aby sa aspoň ukončila riadne
(SIGTERM pred zastavením VM)?

Error Messages/Logs

Steps to Reproduce

STEPS TO REPRODUCE

Poznámka k reprodukovateľnosti: spúšťačom je reštart sandboxu, ktorý sa
nedá vynútiť príkazom. Postup je preto "spusti, počkaj, porovnaj" a
nepotrebuje žiadny projektový kód — stačí jeden proces na pozadí.

1. Otvor session Claude Code on the web (Ubuntu 24.04, Firecracker sandbox).

1. Spusti proces na pozadí, ktorý každých 30 s zapíše čas a uptime VM:

nohup bash -c 'while true; do
printf "%s uptime=%s\n" "$(date -u +%FT%TZ)" "$(cut -d" " -f1 /proc/uptime)" \
>> /tmp/heartbeat.log
sleep 30
done' >/dev/null 2>&1 &

1. Zapíš si výchozí stav:

date -u +%FT%TZ ; cut -d' ' -f1 /proc/uptime ; pgrep -af heartbeat.log

1. Nechaj session 30-60 minút nečinnú (žiadne príkazy).

1. Vráť sa a spusti:

date -u +%FT%TZ ; cut -d' ' -f1 /proc/uptime
tail -3 /tmp/heartbeat.log ; pgrep -af heartbeat.log

OČAKÁVANÉ: proces stále beží, posledný záznam v heartbeat.log je starý
najviac 30 s, a uptime narástol o rovnaký čas, aký uplynul.

SKUTOČNÉ: proces neexistuje, posledný záznam je z času tesne pred
prerušením, a uptime je NIŽŠIE než uplynulý čas -> VM sa medzitým
nabootoval nanovo. Súbor /tmp/heartbeat.log pritom prežije, teda disk
je zachovaný a zmizol len proces.

---
UŽ POZOROVANÉ V TEJTO SESSION (bez tohto pokusu, na reálnej práci):

posledný záznam Postgresu v logu 21:32 UTC
aktuálny čas pri kontrole 23:13 UTC
uptime VM v tom istom okamihu 7 minút
PID 1 process_api (nie systemd)
dátový adresár z 6. 8. (disk prežil)

Za život tejto databázy (6. 8. - 15. 8.) je v logu 87 štartov, z toho 86
po nekorektnom ukončení a 0 záznamov o riadnom vypnutí. Postgres pri
SIGTERM vždy zaloguje "received smart/fast shutdown request" - nula
takých riadkov znamená, že sa nikdy nemohol ukončiť riadne.

---
VARIANT S DATABÁZOU (ak treba vidieť dopad, nie len zmiznutý proces):

1. su postgres -c "/usr/lib/postgresql/16/bin/pg_ctl -D <datadir> \

-o '-p 5433' -l /tmp/pg.log start"

1. Spusti dlhšiu testovaciu sadu (u nás ~3 min).
2. Po prerušení: grep -c "database system was not properly shut down" /tmp/pg.log

rastie po každom výskyte, kým
grep -ci "shutdown request" /tmp/pg.log
zostáva na nule.

Dôsledok, ktorý sa nedá vrátiť: prerušený beh nestihne upratovacie fixtúry
a nechá riadky v tabuľkách, ktoré sú append-only na úrovni databázového
triggera. Nazbieralo sa 10 526 + 1 211 + 2 550 riadkov až po rok 9999,
prideľovač testovacích období minul kalendár a 69 testov padlo na
"ValueError: year 10000 is out of range" - bez súvislosti s meneným kódom.
Upratať sa to dalo len dočasným vypnutím triggerov cez superuser kanál.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.233

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Non-interactive/CI environment

Additional Information

_No response_