interruptible sleep process detektálása és leállítása

Linux-haladó

Adott egy program, amely több példányban is futhat, viszont időként egy-egy process interruptible sleep állapotba kerül (55119-es).

Amikor ebbe az állapotba kerül utána a többi, hasonló process addig nem indul el, amíg ezt a folyamatot ki nem kill-eljük. 

Kérdés: hogyan lehetne detektálni pl. 10 percenként, hogy legalább 30 perce interruptible sleep állapotban van-e ilyen process és ekkor ez kilövésre kerüljön?



admin  5672  0.0  0.0 480704 11320 ?        Ssl  Mar30   1:09 /opt/srv_1 -server
admin 55405  0.0  0.0 878280  9264 ?        Ssl  Mar31   0:12 /opt/srv_1 -server
admin 55805  0.0  0.0 995764 23448 ?        Ssl  Mar31   0:20 /opt/srv_1 -server
admin 55107  0.0  0.0 872104  9236 ?        Ssl  11:21   0:00 /opt/srv_1 -server
admin 55119  0.0  0.0 480836  5956 ?        S    11:21   0:00 /opt/srv_1 -server
admin 55043  0.0  0.0 878524  9464 ?        Ssl  11:37   0:00 /opt/srv_1 -server
  • 181 megtekintés

( golgota | 2021. 04. 01., cs – 22:28 )

Hát én először inkább megnézném, hogy milyen syscall az ami miatt uninterruptible sleep-be kerül és ha enyém a forrás, hát javítanám. Nem egészséges, ha örökre vár egy syscall visszatérésére.

( x-daemon | 2021. 04. 01., cs – 22:28 )

Szerkesztve: 2021. 04. 01., cs – 22:52

systemd tud valami ilyesmit, nemtom jo-e neked

[Service]

Type=notify

WatchdogSec=1800

az a lenyeg hogy indulaskor kapsz egy udg socketet a NOTIFY_SOCKET kornyezeti valtozon keresztul.

indulaskor ezt megnyitod es bekuldod hogy "READY=1\n"

majd bekuldod periodikusan hogy "WATCHDOG=1\n"

ha 1800s-ig nem kuldod be a watchdogot akkor a systemd kilovi

ha azt akarod hogy utana inditsa is ujra akkor ezt is tedd bele a service-be:

Restart=watchdog (vagy alway ha minden leallasra inditsa ujra, de van meg tobb lehetoseg is)
RestartSec=1s

neked aztan fura humorod van...

( iattilagy | 2021. 04. 01., cs – 22:49 )

Úgy kell killelni, hogy legyen corefile és meg kell nézni miben áll.

( vl v | 2021. 04. 02., p – 01:07 )

Régen volt olyan oszlop a ps alx kimenetében, hogy WCHAN, ami az alvó processzeknél mutatta, hogy melyik kernel függvényben várnak éppen. Érdekes módon ez most nálam üres 4.9.152 alatt, de a 4.15-öt futtató Ubuntun még van benne infó.

ps -o pid,wchan=WIDE-WCHAN-COLUMN -o comm -ax

futex_wait_queue_

 

proc/pid/stack alatt ez van

[<ffffffff88d0ce56>] futex_wait_queue_me+0xc6/0x130
[<ffffffff88d0db3b>] futex_wait+0x17b/0x280
[<ffffffff88d0f886>] do_futex+0x106/0x5a0
[<ffffffff88d0fda0>] SyS_futex+0x80/0x190
[<ffffffff89374ddb>] system_call_fastpath+0x22/0x27
[<ffffffffffffffff>] 0xffffffffffffffff
 

futex-et szokták használni mutex-ekhez/condition_variable-ökhöz. Amiket láttam már bug-ként vele (lehet itt tök más a gond):

  • Van futex alapú shared_mutex implementáció: látsz közvetlen előtte más futex függvényhívást is?
  • lehet condition_variable, amit a közben töröl le az egyik szál, miközben a notify_all meg lett hívva egy másikban.

Ha tudsz csinálj egy core dump-ot és küld el a beszállítónak (gcore {pid} abban a könyvtárban, ahova el akarod menteni a fájlt)

https://naszta.hu

Ez valószínűleg egy user-space lock mechanizmus kernel primitívvel megvalósítva. A megakadás pedig ebben az esetben az alkalmazásban rosszul megalkotott lockolási logika, ami deadlockba tud menni. Kéne nézni stack trace-t az alkalmazásban is, amikor ilyet hív.

( zhans v | 2021. 04. 02., p – 12:09 )

köszi, ezek alapján megyünk tovább

( meditor | 2021. 04. 02., p – 12:23 )

Ha az enyém a forrás, akkor az ilyen többmodulos/többpéldányos  cuccokba watchdogot rakok. Van egy supervisor program, ami figyel, és ha kell beavatkozik.

> Sol omnibus lucet.