3

I run Firefox with command xinit /path/to/firefox/binary and it opens a display with Firefox running on it.

Then I push Ctrl +Alt+F1 to go back to console and then I push Ctrl+z to suspend the Firefox into the background.

Then, I push Ctrl+Alt+F7 to go back to Firefox. I expect Firefox to be freezed or non-responsive, however I can still use Firefox with no problem. My expectation is based on my experience when sending other apps to background, like wget. When I send wget to background, the download process is stopped.

Why does this happen?

Improve this question

2 Answers 2

Reset to default
2

Firefox puts itself in the background and detaches from your terminal if you run it from a terminal. Therefore pressing Ctrl+Z is not really suspending Firefox, it probably suspends xinit.

wget and most commandline programs do not have this kind of detaching behaviour. GUI based programs like gedit start mostly like firefox and detach.

I looked if there was some option to prevent this from happening. -foreground seemed a likely option name, but that just pushes the firefox window to the foreground.

Improve this answer
1
  • 1
    Firefox does not put itself in the background. If you run it with an instance already running, the new instance contacts the existing instance and exits immediately; but if you start a fresh instance, it stays in the foreground.
    – Gilles 'SO- stop being evil'
    Apr 27, 2016 at 0:30
1

Pressing Ctrl+Z does suspend the application, as in, it stops running until resumed with a SIGCONT (possibly sent through the fg or bg command in the shell). But…

You're running xinit, not firefox. Pressing Ctrl+Z sends a STOP signal to the application that's running in the foreground, not to other applications that it may have run. So you've only suspended xinit itself, and this doesn't affect the X11 session.

More precisely, pressing Ctrl+Z sends a STOP signal to the foreground process group. This may involve more than one process, but the intent of process groups is that it's still morally a single unit for signalling purposes.

(The same holds for Ctrl+C and SIGINT, and Ctrl+\ and SIGQUIT. On the other hand, SIGHUP when the terminal disappears is only sent to a single process: the session leader, normally the shell; shells in turn send SIGHUP to the jobs they launched.)

xinit runs both the X server and the client in their own process group, precisely so that you can suspend or kill it without killing the whole session. When you send it a catchable signal, it kills the X server, which in turns causes most X applications to exit — so pressing Ctrl+C does bring down the GUI session, but indirectly, not because every client and the server received a SIGINT due to the Ctrl+C. On the other hand, xinit doesn't do anything particular on Ctrl+Z, so that just suspends xinit and leaves the session alone, which is useful when you want to do something else in the terminal where you ran xinit.

Improve this answer

You must log in to answer this question.

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