Zaseklý proces nereaguje na kill -9

[Logik]

Ahoj,běží mi proces, v topu vypadá takto:

Kód: [Vybrat]

%Cpu(s):  1,5 us, 14,3 sy,  0,0 ni, 84,1 id,  0,0 wa,  0,0 hi,  0,1 si,  0,0 st
    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   1149 logik     31  11       0      0      0 Z 100,0   0,0 145:21.36 syncthing

Na sudo kill -9 1149 nijak nereaguje.

Co s tím? Chápu dobře, že se zasekl na nějakém volání v jádře, které ho nepustí "ven", takže jediné, co pomůže, je restart?
Nebo je ještě nějaký způsob, jak ho zabít?
Dík za radu.

[Reklama]

[RDa]

Ten proces nebezi, ma stav Z - zombie:

Zombie (Z): we briefly talked about zombie processes when we discussed system calls. When a process finishes with exit() system call, its state needs to be "reaped" by its parent (calling wait()); in the meantime, the child process remains in zombie state (not alive nor dead).

https://cloudchef.medium.com/linux-process-states-and-signals-a967d18fab64

[Logik]

Ale furt žere 100% procesoru....

[Petr Krčmář]

Ten proces je ve stavu zombie, čili mu byly dealokovány všechny prostředky a čeká na to, až na něj jeho rodič zavolá waitpid. Rodič je v tomto případě init, který zřejmě propásl informaci o ukončení procesu. Ten teď není možné zabít, pokud to neukončí rodič. Pokud zabijete rodiče, tak bude zlikvidován i jeho potomek, ale to je u initu samozřejmě problém.

Mohlo by pomoci zavolat

Kód: [Vybrat]

# kill -SIGCHLD 1
Pokud to nepomůže, pak je třeba pustit gdb, připojit se na rodiče a spustit ručně waitpid za něj. Pokud nevíte, jak na to, existují hotové skripty, které to umí udělat automaticky. Výhodou je, že to nevyžaduje restart rodiče = reboot systému.

[tecka]

Mně není jasné z čeho vyplývá, že rodičovský proces už je init. Pravděpodobnější je, že je to pořád původní rodič a půjde normálně sestřelit.

Kód: [Vybrat]

ps -o ppid -p 1149

[Reklama]

[Logik]

Děkuju za odpovědi. Že je to zombie jsem si nevšiml, to vysvětluje tu "nesmrtelnost" - ale neměla by zombie "nedělat nic"? Tedy to bejt už ukončenej proces? Tendle prokazatelně (podle výpisu i loadu) běžel. Něco tam muselo bejt blbě....

Nicméně bohužel jsem ten stroj musel stejně restartnout z jinýho důvodu (blbo tam ještě něco jinýho), takže víc o tom nezjistím.  V každém případě díky za triky, co s tim.

[FKoudelka]

Mně není jasné z čeho vyplývá, že rodičovský proces už je init. Pravděpodobnější je, že je to pořád původní rodič a půjde normálně sestřelit.

Kód: [Vybrat]

ps -o ppid -p 1149

Nevím, z jaké syntaxe příkazu ps je to výstup, ale nevidím ve výpisu ani <defunct>. Tudíž je možné , že to není sirotek ( viz. p. Skočovský, kapitola “Vyhubení sirotků” :-) pak asi kill -SIGCHLD na mamu.

[Logik]

Update: tak se mi to stalo znova. Tentokrát proces je zcela jistě regulérní zombie, ale nejde zabít ani metodama, co tu radil Petr Krčmář - waitpid v gdb se zavěsí a neskončí, kill -s SIGCHLD 1 proběhne bez efektu.


Sirotek je zombie proces pověšenej přímo pod initem. A zároveň je něco blbě se samotným initem: systemctl daemon-reload "zatuhne navždy", ps a se nedokončí a zavěsí atd....

V logu jsem našel toto:

Kód: [Vybrat]


čen 01 21:46:36 host kernel: BUG: unable to handle page fault for address: 0000000000003af0
čen 01 21:46:36 host kernel: #PF: supervisor read access in kernel mode
čen 01 21:46:36 host kernel: #PF: error_code(0x0000) - not-present page
čen 01 21:46:36 host kernel: PGD 0 P4D 0
čen 01 21:46:36 host kernel: Oops: 0000 [#2] SMP PTI
čen 01 21:46:36 host kernel: CPU: 3 PID: 130 Comm: kswapd0 Tainted: P      D    OE     5.8.0-53-generic #60-Ubuntu
čen 01 21:46:36 host kernel: Hardware name: Dell Inc. Latitude 5590/02N9PD, BIOS 1.16.3 03/05/2021
čen 01 21:46:36 host kernel: RIP: 0010:__clear_extent_bit+0xfa/0x4b0 [btrfs]
čen 01 21:46:36 host kernel: Code: 02 00 00 8b 55 d0 85 d2 0f 85 3f 01 00 00 49 8b 3c 24 48 85 ff 75 08 e9 46 01 00 00 48 89 d7 48 8d 47 f0 48 8d 57 10 49 89 c1 <4c> 3b 77 f0 72 0a 4c 3b 77 f8 76 30 48 8d 57 >
čen 01 21:46:36 host kernel: RSP: 0018:ffffb2e5c03179e0 EFLAGS: 00010206
čen 01 21:46:36 host kernel: RAX: 0000000000003af0 RBX: fffffffffffffffe RCX: 0000000000000000
čen 01 21:46:36 host kernel: RDX: 0000000000003b10 RSI: ffffffffc0654691 RDI: 0000000000003b00
čen 01 21:46:36 host kernel: RBP: ffffb2e5c0317a38 R08: ffff8e9cde4f2230 R09: 0000000000003af0
čen 01 21:46:36 host kernel: R10: ffff8e9943cba240 R11: 0000000000000001 R12: ffff8e9acac8b388
čen 01 21:46:36 host kernel: R13: ffff8e9bb82d0280 R14: 0000000000000000 R15: 0000000000000000
čen 01 21:46:36 host kernel: FS:  0000000000000000(0000) GS:ffff8e9cde4c0000(0000) knlGS:0000000000000000
čen 01 21:46:36 host kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
čen 01 21:46:36 host kernel: CR2: 0000000000003af0 CR3: 00000002099da001 CR4: 00000000003606e0
čen 01 21:46:36 host kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
čen 01 21:46:36 host kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
čen 01 21:46:36 host kernel: Call Trace:
čen 01 21:46:36 host kernel:  clear_extent_bit+0x18/0x20 [btrfs]
čen 01 21:46:36 host kernel:  btrfs_inode_clear_file_extent_range+0x49/0x50 [btrfs]
čen 01 21:46:36 host kernel:  btrfs_destroy_inode+0x135/0x240 [btrfs]
čen 01 21:46:36 host kernel:  destroy_inode+0x41/0x80
čen 01 21:46:36 host kernel:  evict+0x14c/0x1b0
čen 01 21:46:36 host kernel:  prune_icache_sb+0x81/0xb0
čen 01 21:46:36 host kernel:  super_cache_scan+0x169/0x1f0
čen 01 21:46:36 host kernel:  do_shrink_slab+0x14f/0x2a0
čen 01 21:46:36 host kernel:  shrink_slab_memcg+0xd0/0x1d0
čen 01 21:46:36 host kernel:  shrink_slab+0x109/0x120
čen 01 21:46:36 host kernel:  ? shrink_slab+0x109/0x120
čen 01 21:46:36 host kernel:  shrink_node_memcgs+0x72/0x190
čen 01 21:46:36 host kernel:  shrink_node+0x152/0x530
čen 01 21:46:36 host kernel:  balance_pgdat+0x270/0x550
čen 01 21:46:36 host kernel:  kswapd+0x103/0x1c0
čen 01 21:46:36 host kernel:  kthread+0x12f/0x150
čen 01 21:46:36 host kernel:  ? balance_pgdat+0x550/0x550
čen 01 21:46:36 host kernel:  ? __kthread_bind_mask+0x70/0x70
čen 01 21:46:36 host kernel:  ret_from_fork+0x22/0x30
čen 01 21:46:36 host kernel: Modules linked in: usbhid cdc_ether usbnet r8152 mii typec_displayport rfcomm vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) ccm cmac algif_hash algif_skcipher af_alg snd_hda_codec_hdm>
čen 01 21:46:36 host kernel:  processor_thermal_device fb_sys_fops serio_raw dcdbas syscopyarea soundcore ucsi_acpi intel_rapl_common dell_wmi_descriptor typec_ucsi intel_wmi_thunderbolt hid_multitouch cfg802>
čen 01 21:46:36 host kernel: CR2: 0000000000003af0
čen 01 21:46:36 host kernel: ---[ end trace e50abd9f6f57e042 ]---
čen 01 21:46:36 host kernel: RIP: 0010:vfs_getattr_nosec+0x90/0xc0
čen 01 21:46:36 host kernel: Code: 00 00 89 06 41 8b 41 0c f6 c4 08 74 0c 48 c7 46 10 00 10 00 00 41 8b 41 0c f6 c4 20 74 08 48 81 4e 10 00 00 20 00 49 8b 41 20 <48> 8b 40 70 48 85 c0 74 15 81 e2 00 60 00 00 >
čen 01 21:46:36 host kernel: RSP: 0018:ffffb2e5c0bc7e18 EFLAGS: 00010246
čen 01 21:46:36 host kernel: RAX: ffffffff8064c9c0 RBX: ffffb2e5c0bc7e80 RCX: 0000000000000000
čen 01 21:46:36 host kernel: RDX: 0000000000000900 RSI: ffffb2e5c0bc7e80 RDI: ffffb2e5c0bc7f10
čen 01 21:46:36 host kernel: RBP: ffffb2e5c0bc7e18 R08: ffffb2e5c0bc7e30 R09: ffff8e9b6ab18240
čen 01 21:46:36 host kernel: R10: 00000000000007ff R11: 000000000000006f R12: 0000000000000000
čen 01 21:46:36 host kernel: R13: 00000000ffffff9c R14: 000000c0047fa400 R15: 0000000000000900
čen 01 21:46:36 host kernel: FS:  0000000000000000(0000) GS:ffff8e9cde4c0000(0000) knlGS:0000000000000000
čen 01 21:46:36 host kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
čen 01 21:46:36 host kernel: CR2: 0000000000003af0 CR3: 00000002099da001 CR4: 00000000003606e0
čen 01 21:46:36 host kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
čen 01 21:46:36 host kernel: DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
čen 01 21:46:37 host kernel: BUG: unable to handle page fault for address: 000000000000c4f0
čen 01 21:46:37 host kernel: #PF: supervisor read access in kernel mode
čen 01 21:46:37 host kernel: #PF: error_code(0x0000) - not-present page
Takže moje "divoká hypotéza" je, že v kernelu něco spadne, zřejmě neuvolní nějakej zámek, a některý věci v initu pak přestanou fungovat (např. čekání na zombíky), protože je ten zámek blokuje. Asi nic jinýho, než downgrade jádra nepomůže?

 

[Logik]

PS: Jádro je
5.8.0-53-generic #60-Ubuntu SMP
ale zatím jsem nevygooglil nic, k čemu by se to molo vztahovat

[johanson14]

Bug v driveri zrejme zostrelením procesu neopravíte.
Pravdepodobný problém ukazuje RIP:
Následne potom "Call Trace"

[Jan Fikar]

Je to určitě něco v jádře, není v dmesg víc před tou chybou?

Jinak tam vidím něco s btrfs, swap, nebo pamětí obecně. Takže bych zkusil třeba otestovat paměť, vypnout swap (jestli je to možné). Swap náhodou není na btrfs, nebo? Nemáte náhodou zswap?

No a ještě je možnost, že blbne btrfs, tak pustit scrub, zkusit jiný FS, zkusit novější jádro. Btrfs dost často něco opravuje.

[Logik]

Dík za rady, koukám, že přemejšlím stejným způsobem :-), než jsem se zde ptal, tak už jsem udělal BTRFS scrub, memtest paměti, smart na disk, vše se zdá Ok.

Swap je na samostatném oddíle, pro jistotu jsem ho znovuvytvořil. A updatoval jsem na novější ubuntu, bych tam dostal nové jádro, tak uvidím...

[Jan Fikar]

ještě je možnost zkusit bez swapu

Kód: [Vybrat]

sudo swapoff -a