this post was submitted on 16 Jul 2023
16 points (90.0% liked)

Linux

48008 readers
1194 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

My friend was running firefox on linux mint, and it froze and he used xkill to kill firefox. But still it shows up in htop ps -aux. He tried to kill it multiple times but it didn't work. See the pictures for explanation. We had to kill power to shutdown, even systemd can't stop that process.

top 9 comments
sorted by: hot top controversial new old
[–] skullgiver@popplesburger.hilciferous.nl 14 points 1 year ago (1 children)

First of all: make sure to kill the right process. The process selected in your htop screenshot is just a random render process, that won't take out the browser itself. You need to kill the parent process for that.

If kill -9 doesn't work, it may be a zombie process or it may be stuck in a syscall waiting on some kind of I/O operation that isn't timing out/is bugged out/can never complete. For example, if it has done a call into the GPU driver while the GPU driver bugged out, it may be stuck waiting forever.

Normally, zombie processes should terminate when their parent gets killed. However, if the process is orphaned (the parent process died/was killed), init (whatever PID 1 may be on your system) will adopt the process, becoming its new parent, and take over the responsibility to read the exit code.

systemd's init should reap zombie orphans so I believe this is likely I/O or driver related.

If a system is stuck shutting down, you can often force it by pressing ctrl+alt+delete seven times in a row. If that doesn't work, the magic SysRq key combos may help force reboot/halt the system; however, those are often disabled by default so they may be useless when you actually encounter a situation like this.

Yes, I killed the parent process. Also after killing the process with firefox PID, the file equivalent to that process /proc/PID was still there. I think it could be - "likely I/O or driver related" or "stuck in a syscall waiting on some kind of I/O operation that isn’t timing out/is bugged out/can never complete".

[–] palordrolap@kbin.social 2 points 1 year ago (1 children)

kill takes a process ID (i.e. a number) not a process name. Either find the right PID with ps first or use killall, although be aware that killall does exactly what it says: kills all processes matching the string it is given. If you only want to kill one of several Firefox processes that isn't what you want.

Sorry my mistake, it was pkill, but we also tried kill with process id, and we also tried killall. Every method that I knew i tried.

[–] MummifiedClient5000@feddit.dk 2 points 1 year ago (1 children)

Did you literally type kill -9 firefox? Because the kill command normally takes PIDs not process names. killall takes process names, but process names are not always straightforward. Under normal circumstances firefox would exit when X/Wayland goes away though.

Using the sysrq key in the "reverse BUSIER" sequence when your system won't shutdown/reboot is always better than shutting the power on a running system.

Sorry, it was a mistake, I fixed the post. Also I tried many other ways to kill that process. Thanks for the BUSIER tip.

[–] heftig@beehaw.org 1 points 1 year ago (1 children)

Stuck in kernel code, possibly because they tripped an assert. Even if not, if your distribution enabled hung task detection, the kernel will log backtraces for these processes eventually; by default, after 2 minutes of being stuck.

[–] antihero@social.fossware.space 0 points 1 year ago (1 children)

I knew it was something related to kernel. Now I have some some explanation of if this happens again.

[–] brain_in_a_jar@kbin.social 2 points 1 year ago

You can cat /proc/PID/stack to see what it's wedged on in kernel land.

I'm guessing maybe something related to the GPU, maybe some kind of driver bug?

load more comments
view more: next ›