I had several instances of Firefox running, which I suspended. I think I used 'the GUI' (KDE's System Activity), which I think is the same as kill -19. Normally this works fine - I can resume the processes graphically or from terminal. This time, I was trying to fix an X problem, so I restarted X. Got my desktop back, I can still see the suspended processes, but am not sure how to resume them.

In System Activity they no longer have window titles. I tried resuming one (of three), and it .. disappeared ('realized' X had quit?). When I try to start Firefox with one of the suspended profiles, it gives me the 'already running' message. The suspended processes are still taking up memory.

Is there a way to recover my FFox sessions the way they were? Or is my only choice to resume them and let them die, then start again?

Using up to date (K)Ubuntu 12.04, KDE4

  • Sorry if this is a dupe. I do see some Qs that might be related, I'm still reading through them ...
    – hunter2
    Sep 13 '13 at 10:07
  • 1
    Given the way xlib works (the actual connection from X client to server) it has historically not had any provisions for reconnection to a new server. Someone may have come up with a mechanism, but since the X connection is stateful, I doubt it.
    – msw
    Sep 13 '13 at 11:54

An X11 client is storing context data on the X server side. All of it is lost when the server is restarted so there is no way I'm aware of to simply "replug" the client to another server instance.

Should you really want to be able to recover a X11 client after your X11 server has restarted, you would need to first run the client through an intermediary X11 "proxy" server like VNC, Xpra, NX or commercial like Oracle SGD, Citrix and the likes.

  • I guess I was hoping that since Firefox can detect the old process enough to block me from restarting (with the same profile), it could figure out how to recover the session ... dang.
    – hunter2
    Sep 16 '13 at 2:44
  • 1
    Firefox uses a lockfile named .parentlock to avoid the mess that would occur should two instances access the same profile, configuration files, cache etc. This lock file is removed when the process exits so is still there when the process is just suspended. As soon as you wake up firefox, if notices the connection to the X server is lost so it removes the lock file and exits.
    – jlliagre
    Sep 16 '13 at 7:36
  • Gotcha, thanks. // (If you'll indulge me ..) So, a new instance of FF can't access the old memory because it belongs to another process, to accomplish something like what I want would require something like having a 'BG proc' and 'GUI proc' per profile, or like a constantly running FF daemon. Sound right?
    – hunter2
    Sep 17 '13 at 4:29
  • Answer updated to show how this can be done.
    – jlliagre
    Sep 17 '13 at 7:15
  • Thanks! Clever. That's interesting - I'm not sure when I'll use it, but that's a good 'trick' to be aware of, IMO.
    – hunter2
    Sep 17 '13 at 8:58

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.