I had Firefox running on a Parted Magic LiveCD, then (possibly) as a result of a key combination I don't recall, it quickly vanished from screen and Task Bar/Window List.


  1. ps ax | grep firefox returns the below (and the unneeded grep firefox line). Both ps and the GUI Task Manager, show firefox with seemingly unchanging RSS, VM-SIZE and 0% CPU usage.

    johndoe      1916 36.6 14.0 923772 504372 tty1    Sl   13:30  12:15 firefox

  2. pstree | grep firefox returns:


  3. strace -p 1916 returns, and seemingly stays on this line forever:

    futex(0xac975608), FUTEX_WAIT_PRIVATE, 1, NULL

I understand from an answer to What do the STAT column values in ps mean? that S (in Sl) indicates that the process is in an interruptible sleep state.

Can anyone elaborate as to what the state is, in more detail?


I will start a new question, with more specifics on my distro, to address the original 2nd question.

  • @Braiam - Done. I have been reluctant to do this, as the first time I did, somehow the help turned away from the problem, into discussions based on the belief I was using Parted Magic as my full time distro. I sincerely hope that this will not happen this time :(
    – user66001
    Commented Oct 20, 2013 at 3:30

3 Answers 3


@msw did a good job explaining your 2nd Q, and some of your 1st:

B) Suggest any relatively-easy ways to regain any form of control, to (at the very least) save the tabs I had annoyingly opened in Private Browsing mode?

So I'll try and address your 1st Q a bit more:

A) Elaborate as to what the state is, in more detail?

The state values Sl (That's a lowercase L):

   S    Interruptible sleep (waiting for an event to complete)
   l    is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)

                 lifecycle of process

   R  running or runnable (on run queue)
   D  uninterruptible sleep (usually IO)
   S  interruptible sleep (waiting for an event to complete)
   Z  defunct/zombie, terminated but not reaped by its parent
   T  stopped, either by a job control signal or because
      it is being traced

Further details can be seen in the signal man page, man 7 signal, as well as in this tutorial, titled: Linux process states.

  • 1
    @user66001 accept the answer.it also help me thanks. Commented Feb 22, 2018 at 6:33

You did not do anything to the Firefox process. It was already in state S before. “Interruptible sleep” effectively means idle. The process is waiting, and will wake up when it receives an input. That's the normal state of a process unless you catch it while it's busy.

You have made the window disappear. Maybe you sent it to a different desktop. How to bring it back the “normal” way is entirely dependent on your window manager, which you didn't specify.

You may be able to retrieve the window with other tools but it somewhat depends on what exactly happened to it and whether your window manager cooperates. Try wmctrl. First list the Firefox windows with wmctrl -l | grep Firefox. Note the window ID in the first column, say 0x12345678. To bring a window back to the current desktop, use wmctrl -R 0x12345678; alternatively, use wmctrl -a 0x12345678 to switch to its desktop. To maximize it (which takes care of windows outside the screen or shrunk to a single pixel), run wmctrl -r 0x12345678 -b add,maximized_vert,maximized_horz. Alternatively, move and resize the window with wmctrl -r 0x12345678 -e 1,50,100,1000,800. You may need to unshade or unhide the window with wmctrl -r 0x12345678 -b remove,shaded or wmctrl -r 0x12345678 -b remove,hidden.

  • Thanks Gilles - This may sound unusual, but I am not sure which Window Manager I am running. Could it be LXDE (Listed in an about LXPanel box)? Also, wmctrl doesn't seem to be available on my distro - Please forgive my ignorance, but can wmctrl just be downloaded and run, or must it be installed (dependencies, etc)?
    – user66001
    Commented Oct 19, 2013 at 23:13
  • @user66001 LXDE is a desktop environment. Its default window manager is Openbox (I'm not sure if it supports a different one). If your distribution doesn't have wmctrl, you can try downloading the source and compiling it. It depends on a few libraries, but none of them are exotic, they should all be provided by your distribution. If you have xdotool, it may be able to do all of these, or at least the one that's useful, so try it out (look at the window commands and the desktop and window commands in the manual). Commented Oct 19, 2013 at 23:17
  • Ah, thanks. No xdotool either - When you mean it "may be able to do all of these", are you talking about compiling wmctrl, or the operations that you can perform with it? Can you point me to any recommended guides on compiling Linux sources (New to Linux, from a Windows environment)?
    – user66001
    Commented Oct 19, 2013 at 23:47
  • @user66001 I meant that xdotool and wmctrl have similar functionality (as far as what you need here, they differ in what else they offer). If you're new to Linux, I recommend a distribution with more packages. If you're running RHEL or a variant such as CentOS or Scientific Linux, there's a package on Repoforge. If you want to build from source, read this — but it would be easier to install a package if you can find one. Commented Oct 20, 2013 at 0:10
  • Any difference in which tool should be easier to build? Also, if one didn't have a package manager in their distro, what type of ?package? should one be looking for (I guess that this is a illogical question, but just in case I am wrong in assuming a package is just a bundle of binaries, with dependencies listed, and config changes, thought I would ask)?
    – user66001
    Commented Oct 20, 2013 at 3:04

It is possible for X clients to lose their connection and somehow not be notified of it. The process will often wait on the socket across which nothing will ever come, leaving it in an uninterruptible sleep.

For Firefox only (and some other programs like Gvim or Chrome which make special provisions for storing state in failure) a simple:

$ kill -TERM pid

will give the process a chance to save the list of open tabs, but I wouldn't count on form contents or other state to be kept.

  • It's rather unlikely that a local X client would lose the connection with the X server, especially as a result of pressing a key. Killing Firefox wouldn't save information about windows in private browsing mode. Commented Oct 19, 2013 at 23:01
  • I make use of Lazarus, and (when not using Private Browsing mode to try and switch around my primary gmail account, to open up gdocs to view/edit documents using info from websites in adjoining the tabs, without logging out of all my gmail accounts - Grr, Google) have FF "Remember my windows & tabs from last time", so I only care about the tabs open in the Private Browsing mode. So, while it is good to know the above argument to kill, I doubt that FF would save my tabs in this situation. Any way for FF to reattach to X?
    – user66001
    Commented Oct 19, 2013 at 23:05
  • "Any way for FF to reattach to X?" because I've never been able to figure out how the window can be unmapped/destroyed without the client process getting a signal, I assume that the socket from the FF program to the UI remains open. So long as a process is connected to a socket, I know of no way that any process could tap into that. (Now that you caused me to think about it, I suspect this comes of a protocol error between the X server and client which is insanely difficult (i.e. I'd never try) to debug).
    – msw
    Commented Oct 19, 2013 at 23:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .