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.

  • Skull giver@popplesburger.hilciferous.nlEnglish
    16·
    1 year ago

    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.

    • antihero@social.fossware.spaceOPEnglish
      6·
      1 year ago

      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”.

  • heftig@beehaw.orgEnglish
    4·
    1 year ago

    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·
        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?

  • palordrolap@kbin.social
    51·
    1 year ago

    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.

    • antihero@social.fossware.spaceOP
      8·
      1 year ago

      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.dkEnglish
    2·
    1 year ago

    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.