Proč něco zabíjí službu v systemd?

[bmansvk]

Ahojte,

mam problem, ze mi nieco/niekto zabije systemd sluzbu a ja neviem zistit dovod preco sa to deje.

V logu sa objavi nasledovne:

Kód: [Vybrat]

Aug 04 10:58:14 cam01 systemd[1]: service1.service: Main process exited, code=killed, status=9/KILL
Aug 04 10:58:15 cam01 systemd[1]: service1.service: Failed with result 'signal'.
Aug 04 10:58:25 cam01 systemd[1]: service1.service: Scheduled restart job, restart counter is at 2.
Aug 04 10:58:25 cam01 systemd[1]: Stopped service1 service.
Aug 04 10:58:25 cam01 systemd[1]: Started service1 service.

Predpoklad je, ze niekto posle tomu procesu signal 9 (SIGKILL). Auditd hlasi nieco taketo:

Kód: [Vybrat]

time->Fri Aug  4 10:58:14 2023
type=PROCTITLE msg=audit(1691146694.920:1618335): proctitle="(null)"
type=OBJ_PID msg=audit(1691146694.920:1618335): opid=121629 oauid=-1 ouid=0 oses=-1 ocomm="dotnet"
type=SYSCALL msg=audit(1691146694.920:1618335): arch=c000003e syscall=62 success=yes exit=0 a0=1db1d a1=9 a2=7ffa90024a2a a3=7ffa905a67e8 items=0 ppid=1 pid=121629 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=2E4E4554205369676E616C2048616E exe="/usr/share/dotnet/dotnet" key="process_kill"

Nie som z toho mudrejsi, proctitle hlasi "null". Mozno by to mohol robit kernel? Co znamena proctitle="(null)"?

V kernel logu nie je vobec nic, ziaden OOM killer ani nic podobne.

Systemd sluzba je nasledovna a nie je na nicom zavisla ani nic na nej nezavisi:

Kód: [Vybrat]

[Service]
WorkingDirectory=/opt/sluzba1
ExecStart=/usr/bin/dotnet /opt/sluzba1/sluzba1.dll
Restart=always
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=service1
User=root

Deje sa to cca kazdu hodinu. Jedna sa o proprietarnu sluzbu, ktora bezi v .NETe na Linuxe. OS je Ubuntu 20.04.

Ta sluzba este obcas padne aj na:

Kód: [Vybrat]

Jul 20 18:53:40 cam01 systemd[1]: service1.service: Main process exited, code=killed, status=6/ABRT
Jul 20 18:53:41 cam01 systemd[1]: service1.service: Failed with result 'signal'.
Jul 20 18:53:51 cam01 systemd[1]: service1.service: Scheduled restart job, restart counter is at 1.
Jul 20 18:53:51 cam01 systemd[1]: Stopped service1 service.
Jul 20 18:53:51 cam01 systemd[1]: Started service1 service.

Ale tam je to jasne preco sa to deje, proces padne na ABRT (tam aj vidim v logu, ze ten proces crashne a skonci to na ABRT). Ale preco je v tom hornom pripade signal KILL? Aky je dovod, ze nieco (jadro?) posle procesu KILL? (jeden dovod ma napada a to je OOM v jadre, ale tu v logu nic nie je)

[Reklama]

[_Tomáš_]

to vypadá na OOM killer, možná jen ho nemáš správně logovaný, co ukazuje dmesg -T? Zkus si tam grepnout třeba killed process, jestli tam tvůj proces nebude

Další důvod proč proces může takhle ošklivě být zavražděn je page fault, seq fault, ale to bys viděl ve statusu

[bmansvk]

Bohuzial v logoch nic nie je. Skusil som zaplnit celu pamat jednoduchym skriptom v Perle a v logu vidim normalne, ze OOM killer proces zabil. Takze logovanie funguje.

to vypadá na OOM killer, možná jen ho nemáš správně logovaný, co ukazuje dmesg -T? Zkus si tam grepnout třeba killed process, jestli tam tvůj proces nebude

Další důvod proč proces může takhle ošklivě být zavražděn je page fault, seq fault, ale to bys viděl ve statusu

[vcunat]

OOM killer jsem viděl posílat pouze 9/KILL, rozhodně ne ten druhý 6/ABRT, což je typicky C assert() nebo něco obdobného.

[z_sk]

https://stackoverflow.com/questions/3413166/when-does-a-process-get-sigabrt-signal-6

[Reklama]

[xitop]

Skúste "killsnoop" https://github.com/iovisor/bcc/blob/master/tools/killsnoop.py

[e3k]

nechcem velmy provokovat ale nazov threadu my mal by skor byt "Proč systemd? "
mozno tam je odpoved na tento problem.

[_Jenda]

nechcem velmy provokovat ale nazov threadu my mal by skor byt "Proč systemd? "
mozno tam je odpoved na tento problem.

Možno ne. Ještě se nevyřešilo jestli to vůbec dělá systemd, případně jestli by stejný problém nastal i u obdobného nastavení s nějakým jiným správcem služeb.

[bmansvk]

Neprisiel som na nic, preco sa to deje, ale:

- nezabija to systems, ale kernel. Ked som sluzbu spustil rucne v konzole, tiez to kernel zabil
- v kernel logu nie je vobec nic o tom preco sa to deje (ziaden OOM)
- vydrzi to cca hodinu a potom to vzdy kernel zabije a v ziadnom logu nie je nic o tom
- skusil som dat i posledny HWE kernel z ubuntu 22.04 a deje sa to rovnako

[_Jenda]

Neprisiel som na nic, preco sa to deje, ale:

- nezabija to systems, ale kernel. Ked som sluzbu spustil rucne v konzole, tiez to kernel zabil
- v kernel logu nie je vobec nic o tom preco sa to deje (ziaden OOM)
- vydrzi to cca hodinu a potom to vzdy kernel zabije a v ziadnom logu nie je nic o tom
- skusil som dat i posledny HWE kernel z ubuntu 22.04 a deje sa to rovnako

Ten killsnoop.py funguje a říká něco? To mi přijde dost jako řešení na tohle.

[bmansvk]

Skusil som ten killsnoop.py (nevsimol som si vyssie, ze mi to uz niekto skor odporucil, moja chyba) s nasledovnym vysledkom (vyfiltroval som killy, ktore s tym nemali suvis, napr. sshd):

Kód: [Vybrat]

# ./killsnoop.py -s 9
TIME      PID      COMM             SIG  TPID     RESULT
19:26:21  1656631  IndepExecContex  9    1656631  0
19:26:21  1657247  .NET Signal Han  9    1657247  0

Procesy mali tieto PIDy:

Kód: [Vybrat]

# ps auxf | grep Eocortex
root     1656631  209  3.5 123537844 2336520 ?   Ssl  19:26  15:04 /usr/bin/dotnet /opt/Server/Server.dll
root     1657247  9.5  3.1 95387972 2068484 ?    SNl  19:27   0:36  \_ dotnet /opt/Server/Gateway.dll

Podla toho vypisu sa zda, ako keby sa ten proces zabil sam. Asi to naozaj mozne je (https://stackoverflow.com/questions/7851121/can-i-kill-a-process-from-itself), ale netusim preco to ten SW robi. Ale to uz my tu asi nevyriesime...

[kvr kvr]

Proces může zabít kohokoliv kde má práva, včetně sám sebe.  Dokonce existuje funkce `raise`, která pošle signál na sebe sama.

Ten ABRT smysl dává a může to být ošetření fatální chyby dotNet runtime - v C je to typicky výsledek `abort()` nebo selhaného `assert`.  KILL je zvláštní, ale možná to dotNet runtime nebo nějaká knihovna řeší takhle místo ABRT.

V každém případě by šlo asi dát breakpoint na `raise()` nebo `kill()` a zjistit stacktrace, kdo se sestřelí.  Taky bych čekal, že aplikace bude mít nějakou snahu zalogovat fatal error předtím, než se zabije - nějaké lokální soubory, dump nebo system log atd.