Conversation
Lucy [hiatus era] 𒌋𒁯
lucy
is there a way to kill a process more aggressively than pkill -9?
like, just delete the entry in the scheduler and free the memory it should basically just "wipe these bytes" and not give a shit about the process. how come killing is in NOT gracefully ending a process is such a hussle? "oh no that could cause trouble" the program is STUCK i could wait until the heat death of the universe, or kill it now and deal with the aftermath. what is this, android? let me take responsibility smh.
like, just delete the entry in the scheduler and free the memory it should basically just "wipe these bytes" and not give a shit about the process. how come killing is in NOT gracefully ending a process is such a hussle? "oh no that could cause trouble" the program is STUCK i could wait until the heat death of the universe, or kill it now and deal with the aftermath. what is this, android? let me take responsibility smh.
5
0
3
mia (developer mode)
mia@shrimptest.0x0.st@lucy if sigkill doesn’t immediately end the process there’s either a kernel bug or it’s stuck waiting for i/o for some reason…
1
0
0
mia (developer mode)
mia@shrimptest.0x0.st@lucy the kernel is stuck in a syscall waiting for dirty pages to flush; there are no means to interrupt that
1
0
0
Lucy [hiatus era] 𒌋𒁯
lucy
2
0
3
mia (developer mode)
mia@shrimptest.0x0.st@lucy you can adjust your vm config to reduce the amount of dirty pages it allows before it forces a flush to disk
have you tried attaching a debugger or strace to a process that’s stuck like this to see what’s going on?
1
0
0
stupid hot girl
zvava@f.619.hu@lucy@netzsphaere.xyz @mia@shrimptest.0x0.st +1 @torvalds@social.kernel.org lucy can be trusted with weapons of mass destruction
0
0
2
SIGKILL is the aggressivest way of doing it, it might be appearing in process lists just because the kernel is busy cleaning up the memory or something dumb like that, the process itself should no longer be executing.
Asshole sounding advice: [spoiler]Try adding
Asshole sounding advice: [spoiler]Try adding
-l to your pkill, there's a very small chance you actually didn't send the signal to the right process.[/spoiler]
1
0
1
GNUkko Sauvage (eris-ng) 
eris@p.enes.lv
It's better to let the kernel do it than have to restart the computer because some process crashed before releasing a lock on a file making it inaccessible now.
2
0
0
mold@yourwalls.today
mold@yourwalls.today
2
0
3
Lucy [hiatus era] 𒌋𒁯
lucy
0
0
2
@lucy
>how come killing is in NOT gracefully ending a process is such a hussle? "oh no that could cause trouble"
It's not that it would cause trouble, is that it will cause trouble.
Remove a from a sentence and software will read or write back something in that place even tho it's not necessarily what it should read or where it should write.
Otherwise yes you could do that if people added it.
>how come killing is in NOT gracefully ending a process is such a hussle? "oh no that could cause trouble"
It's not that it would cause trouble, is that it will cause trouble.
Remove a from a sentence and software will read or write back something in that place even tho it's not necessarily what it should read or where it should write.
Otherwise yes you could do that if people added it.
0
0
0
mangeurdenuage 
🌿 
mangeurdenuage@shitposter.world
0
0
1
mangeurdenuage 🌿
mangeurdenuage@shitposter.world
0
1
1
GNUkko Sauvage (eris-ng)
eris@p.enes.lv
Yes yes I know, it was a general example. Here's an example of the hypothetical Linux that doesn't bother to clean up after processes: Web server binds to :80, crashes, kernel doesn't clean it up, now you can't bind to that port again AKA you can't just restart the webserver. Go have fun with commandline tools to forcefully close an open socket or restart your computer.
CC: @lucy@netzsphaere.xyz
CC: @lucy@netzsphaere.xyz
1
0
3
GNUkko Sauvage (eris-ng)
eris@p.enes.lv
Most probably it's swapping some memory (your guess whether that memory is actually needed), perhaps it's waiting for some hardware to respond
Wait hold on a second, is it a zombie process? It might just mean that the parent process hasn't bothered to wait for its child's death yet and everything is actually cleaned up already.
Wait hold on a second, is it a zombie process? It might just mean that the parent process hasn't bothered to wait for its child's death yet and everything is actually cleaned up already.
0
0
0
mia (developer mode)
mia@shrimptest.0x0.st
0
0
3
mold@yourwalls.today
mold@yourwalls.today
1
0
2