What does the "interruptible sleep" state indicate?

Question

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.

However:

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:

   init─┬─2*[ROX-Filer───firefox───25*[{firefox}]]

   
   

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?

EDIT

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

Answer 1

@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)

                 

PROCESS STATE CODES
   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.

Answer 2

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.

Answer 3

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.