Wandering Thoughts archives

The weird effects of Firefox's remote control on Unix

I hope that Firefox's remote control feature is reasonably well known, but I suspect most people don't know about the surprising and relatively weird effects it has in the Unix version of Firefox; certainly it surprised my co-workers when they stumbled across it.

(Remote control is the feature where if you already have a running Firefox and try to start another one, it will just open a new browser window (or tab) in the first one.)

The root of the surprising behavior comes from how Firefox's remote control works. Rather than use a conventional IPC mechanism (Unix domain sockets, for example), instances of Firefox communicate with each other through X properties. Because X properties are not a per machine thing like Unix domain sockets, the Firefox remote control is global; a Firefox on a machine that you've ssh'd in to can remote control your local Firefox (and vice versa).

(This is what surprised my co-workers; they expected it to be a per machine and per user thing.)

The default Firefox setup on Unix is quite insistent on using remote control if at all possible, to the point where it is impossible to start two copies of Firefox, even on different machines. This can periodically be annoying, for example if you really need to do some particular browsing from a specific machine but don't want to shut down your regular Firefox session.

(It can also be puzzling if you don't realize what's going on; you might find that downloaded files aren't where they're supposed to be, or that some machine's web-based control interface just doesn't seem to be responding.)

Fortunately this behavior is all in the firefox wrapper shell script, which you can modify to get around the issue; see the check_running function and where the ALREADY_RUNNING variable gets used. Note that having more than one Firefox running will make any remote control stuff you do potentially confusing, since you don't know which one will get remote controlled.

The various sorts of backgrounding in Unix

In Unix, there's several ways to put processes into the background, each with its own different set of effects, because Unix processes have various sorts of connections to your foreground shell session: their process group, whether or not they are ignoring SIGHUP signals, open file descriptors to your tty, and even whether or not the process has a controlling tty.

So, in order of increasing isolation, Unix has:

• simple backgrounding, where you start the program with & and the shell doesn't wait for it to finish. With a job control shell it also means that the process won't get a SIGHUP when you exit the session.

• insulating the process from your session exiting. People using job control shells just redirect standard input, standard output, and standard error away from the tty, because their background processes are already insulated from the end of session SIGHUP. People not using job control shells use nohup to start the program with SIGHUP ignored.

  (nohup also does the redirection for you, if you let it.)

• 'daemonizing' the program, totally detaching it from your terminal. On modern versions of Unix this just requires calling the setsid() system call (as well as redirecting the standard file descriptors and so on); unfortunately this is generally not available in a convenient program for shell scripting.

  (If you are being really thorough you also want to change the current directory to some known good location like /, just so that the daemon doesn't wind up forcing some undesired filesystem to stay mounted.)

For a true daemon program, there are various moderately undesirable effects of still having a controlling terminal (and besides, you can be keeping a pseudo tty busy, preventing it from being reused). Most everything else doesn't care, so most people don't need to worry about achieving full daemonization.