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.

    • antihero@social.fossware.spaceOPEnglish
      6·
      2 年前

      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
    51·
    2 年前

    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.

  • heftig@beehaw.orgEnglish
    4·
    2 年前

    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.

      • brain_in_a_jar@kbin.social
        3·
        2 年前

        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?

  • MummifiedClient5000@feddit.dkEnglish
    2·
    2 年前

    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.