1

I recently upgraded my PC to Ubuntu 17.04 (about a month ago) and so far, I really like it. There's just one issue which keeps happening (3 times so far) that is getting REALLY annoying, and I just don't understand why it's happening.

Conditions:

This only seems to happen when I have a relatively large number of tasks running (ex: 3 tabs of StackOverflow + 2 tabs of Youtube in Firefox, 5 Java projects in Eclipse, and a terminal window), and only after about 3 hours of continuously running Firefox.

Things Get Weird:

Then, the following happens:

  1. Firefox stops responding to any form of input, and the window turns grayscale, indicating an unresponsive process.

  2. I attempt to close the window, which takes about 3 minutes longer than usual, and only after I right-click the icon on the taskbar & click "Quit"

  3. I double-click the taskbar icon to reopen Firefox, only to have the icon flash for 5 minutes, before deciding not to open at all.

  4. I open a new terminal window, which takes about 5 times longer than it usually does, and I run top to see what's causing the hold-up.

  5. At the top of top, I see an entry for "firefox", started by my user, occupying 99-100% of processor resources.

  6. I hit Ctrl+C to quit top, and run kill [PID], where [PID] represents the process's PID listed in the left column of top.

  7. I run top again, only to find that "firefox" still isn't dead, and is still taxing my computer's resources.

  8. I hit Ctrl+C again, and try kill -9 [PID], which I'm told should always work in situations like this.

  9. I run top again, only to find that "firefox" STILL WON'T DIE.

At this point, the taxing the process is doing on my CPU will have made my system practically unusable, eventually making the entire system unresponsive (to the point that Ctrl+Alt+T won't even bring up the terminal anymore), and I'm forced to unplug my computer from the wall, and reboot it.

Please Help

I don't know what's going on, and from what I know, it shouldn't even be possible for a Firefox process to survive kill -9, and I really do appreciate any help all of you can give me in preventing this problem from continuing.

<Note>: I apologize in advance if this turns out to be a dumb question. I've only been using linux on a daily basis for about a year now, so I'm still relatively new to a lot of this (but I look forward to learning).

UPDATE

I was just now working in Eclipse, downloading a new software package, when the same thing happened to Eclipse, ruling out Firefox as the problem.

6
  • 2
    You may try killall firefox
    – Anwar
    May 27, 2017 at 4:06
  • 1
    Just so you know, you can kill from within top. Just press k, enter the PID (or press Enter for the top item), and the signal number you want (15 for normal or 9 for kill -9; pressing Enter without a signal uses 15). May 27, 2017 at 19:39
  • 1
    Here are some details of how a process can escape, for some time, a kill -9: unix.stackexchange.com/a/5648 . If you own the process, then its possibly stuck, or rather running wild, in a devices driver or other kernel code. And no, not at all a dumb question. Ineffective kill -9 is definitively a strange case.
    – Harald
    May 27, 2017 at 20:43
  • @ChaiT.Rex Thank you! I didn't know that, but I'll be sure to remember for next time this happens!
    – user575724
    May 28, 2017 at 20:58
  • 2
    Ah, I was mostly referring to "processes cannot block SIGKILL. But kernel code can". 'D' state is the opposite of near 100% CPU load, indeed. But in principle, if a device driver executes a loop forever, you would see this behaviour and not 'D' state. This unix.stackexchange.com/a/132081 may help to see whether the process is burning CPU in user mode or in the kernel. kernel -> likely a kernel/device driver bug, user -> no idea any more, maybe just wait really long (5 minutes, 10?) after kill -9 to give the signal a chance to arrive.
    – Harald
    May 29, 2017 at 5:25

3 Answers 3

1

You could start by trying something simple first on the basis that more than one process might be involved. Instead of kill try being less specific with pkill firefox and, if that doesn't work, sudo pkill firefox.

If that fails you probably need to look at what might be holding firefox open. There are a number of posts on this board under the search what process is holding it open or can not kill process but you might start with this one.

5
  • Thank you so much for your quick response! I can't accept your answer just yet, as the problem is somewhat infrequent & hard to reproduce, but I'll follow your instructions & let you know if it worked as soon as I can.
    – user575724
    May 27, 2017 at 14:14
  • pkill is no different in effect than kill. If kill -9 does not work, pkill won't either.
    – Harald
    May 28, 2017 at 18:01
  • @Harald, would it make a difference if there was another process of Firefox which was keeping the one I keep trying to kill alive? I'm not sure if this is the case, but it might be a possibility.
    – user575724
    May 28, 2017 at 20:55
  • @ChefCyanide I would not know how this keeping alive should work. A problem that would look similar is if firefox keeps getting restarted with high frequency, but then you would see a different pid in top all the time.
    – Harald
    May 29, 2017 at 5:11
  • 1
    I agree that pkill may not make a difference and investigating further into what's holding or reopening Firefox may be required. As it will kill less selectively it might work so would seem worth trying. On further thought, if pkill didn't work my next step would be to completely uninstall Firefox & remove associated directories for a clean reinstall. Then I'd take the bigger step and monitor it to analyse what might be holding it open.
    – John 9631
    May 29, 2017 at 11:28
0

I am experiencing the same thing, also with Ubuntu 17.04, and I have found out that the problem does not involve only Firefox. Rather, in these cases all network connections calls hang. Since these are system calls (going through the OS kernel) the concerning processes cannot be killed by any means, as kill works only on return from a system call. It makes no difference if you use kill, killall, pkill, or xkill.

For instance I had an open terminal and used it to do a ping on a network address. That ping process could not be killed either.

When the problem occurs I cannot even power down my system regularly. The only thing that works ist the magic SysRq key (description available in several languages), which allows a safe shutdown (REISUB). If you are experiencing the problem frequently I advise you to enable that way of shutting down the system.

3
  • 1
    I was just about to update the question after the same issue happened to an instance of Eclipse, when I saw your answer! I think you're right about it being a kernel issue, and the best solution at the moment seems to be to either revert back to 16.10, or just to take the opportunity to finally make the jump to Debian or Arch, as I have long felt that they may be more suited to my needs.
    – user575724
    May 31, 2017 at 2:27
  • 1
    FWIW, these processes are in "uninterruptible sleep".
    – muru
    May 31, 2017 at 2:32
  • The phenomenon hasn't happened for me in a couple of weeks, so I hope the issue has been fixed.
    – Renardo
    Jul 23, 2017 at 15:55
0

This probably isn't the best idea, but if there isn't another option, open a terminal and type

xkill

this will turn your cursor into X, then select the firefox window, and it should close. Also, if your computer becomes too frozen to even do that, do CTRL + ALT + F2, login, and type

sudo service lightdm restart

and that will restart lightdm, allowing you to login again. Please note that this method will close all windows, and will result in unsaved data to be lost.

If all of the above solutions fail to work, try

killall firefox

to kill the firefox process(es).

1
  • Very useful to know! Unfortunately, the window in this case is closing properly, but the unkillable "firefox" process continues to run in the background.
    – user575724
    May 28, 2017 at 20:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy