Running Mozilla processes on Linux

If you're a close observer of such things, you might notice that running a Mozilla browser results in more than one process or thread being started, and that the number of processes grows and shrinks. A closer look at that is an opportunity to study both Mozilla and process creation on Linux. That's the subject of this tip.

In order to begin, the magic commands you need are "ps," "watch" and "lsof." Start Mozilla or Firefox as you normally would, and then turn to the command line, say in a Gnome Terminal or an xterm. From there, try:

ps -Hfu$LOGNAME

The resulting output should show a neat hierarchy of half a dozen processes all with "mozilla" in their names (or "firefox" as the case may be).

If you use this longer version:

watch ps -Hfu$LOGNAME

then the same display results, but it's updated every two seconds. This updating display is a good way to see how the set of mozilla processes changes over time. You can start this program before Mozilla starts, too.

The hierarchy of processes shown seems to say that there's a lot going on inside Mozilla, but it's not as complicated as it seems.

The topmost Mozilla process is just a shell script named "mozilla" or "firefox". For the convenience of distribution providers, admin people and installers, some twiddling can be done in here if necessary. This script ultimately calls another, which is always called run-mozilla.sh. This second script sets up the runtime environment for the Mozilla Platform, including some options that make debugging easier for developers. Finally, the platform itself is launched: usually a binary named mozilla-bin or firefox-bin.

The mozilla-bin (or firefox-bin) binary appears several times in the ps list. That's because there are several separate threads of control running inside the Mozilla platform. That is responsible for the number of processes at work. Two of the most important threads are the "main UI thread," responsible for user input and output via X11 and Gtk, and the JavaScript interpreter thread. There are, however, other threads as well.

If the user attempts to display two different Web sites in two different windows, then two separate Internet DNS lookups are required. Mozilla does simultaneous DNS lookup using a thread for each lookup. Such threads hang around for a bit afterwards in case you need them again; they don't die straightaway. One of these DNS threads is supplied at startup time in order to fetch the browser home page. That's why the number of Mozilla processes can reduce slightly after start up if the browser stands idle.

Two other examples of temporary processes are those of timers and Java. If any JavaScript code uses timer mechanisms like setTimeout(), then a thread starts to cater for those timed events. Similarly, if the Java subsystem starts up, that requires a thread as well.

Such a large array of processes might seem like an overhead, but it isn't. Firstly, all the non-script processes run from the same binary program. Under Linux, large portions of those binaries are shared between like processes: the code part; parts of any shared libraries; even some of the data is shared.

You can confirm this with the "lsof" command. It is used to sticky-beak inside a running process to see what files are being used. A convenient syntax which picks up all the processes starting with "moz" is:

lsof -c moz > /tmp/mytemp

Examine the dumped "mytemp" file and you'll see that all the Mozilla processes have the same sets of files open. They're identical in structure, but not in action -- each one performs a different task.

Fortunately, this multi-thread complexity is well-hidden by the platform. At the application level, Mozilla provides a single, unified interface to the programmer or user.