Xvfb: A Conversation System Admins Should Hear

SAN FRANCISCO (04/28/2000) - REMUS: Hey, Romulus, I was just reading about this thing called Xvfb. Have you ever heard of it?

ROMULUS: Yeah. It's actually an acronym; it stands for X virtual frame buffer.

REMUS: And that is...?

REMUS: A dummy load. The X Window graphical user interface (GUI) defines an architecture of client applications that send graphical instructions to a display server.

REMUS: A punching bag that just hangs there and takes it? What's the good in that?

ROMULUS: Lots of good. There are plenty of useful tests you can run on a graphical application without ever seeing its display: timing tests, tests that make sure that it adjusts to different color depths and environment parameters, tests of command-line arguments and other external interfaces, load testing, code-coverage profiles, and so on. Smart quality-assurance engineers certainly know about Xvfb.

REMUS: So testers like it. Is that all?

ROMULUS: Only the beginning. Here's where it comes up most often: Someone says to his buddy at work, "I've got this cool image converter/graph generator/network monitor/whatever that I want to use to generate daily reports for my boss. I've got it all figured out, and it runs automatically, but when I put it in crontab it doesn't work. Now what?" That person probably needs Xvfb.

There are a lot of situations like that: an application insists on a DISPLAY, but doesn't really require anyone to see what's there. Xvfb is great for such jobs.

REMUS: Sounds cool. What else?

ROMULUS: Well, it's not precisely true that Xvfb simply throws away all the graphical messages it receives. In fact, it can be configured to render its data into a kind of image that's kept in a specific location in memory. An engineer could start a big headless aerodynamic calculation (i.e., one without a display), walk away from it for a week, then connect the memory area to a real display screen to peek at a snapshot of the calculation in progress.

REMUS: Cool. That sounds a little like virtual network computing (VNC).

ROMULUS: You're right; users get some of the same benefits -- persistence and relocatability across processes -- from VNC. In fact, many administrators also recommend VNC for automation. When someone has an application that insists on a DISPLAY, one solution is to configure VNC as a dummy X server. Even in domains such as this, where the capabilities of VNC and Xvfb overlap, each also has unique features. They're both valuable.

REMUS: You make it sound as though there's something wrong with using VNC in a crontab.

ROMULUS: If it works for you, I'm all in favor of it. VNC has a different security profile. As much as I like VNC, I feel I have to be more careful in configuring it, because it opens more cracks that bad guys might exploit. Xvfb is simply lighter weight. If all you want is to automate X service, Xvfb ought to be quicker to set up than VNC REMUS: Sounds like something I could use. So where do I buy it?

ROMULUS: You don't. It's freely available under a license from The Open Group.

REMUS: Nice. When was this released?

ROMULUS: Years ago, it's ancient. It appeared with X11R6 in May 1994.

REMUS: Why haven't I heard of it before?

ROMULUS: Because the X Consortium doesn't specialize in marketing. Just watch, once you start using Xvfb, you'll wonder how you ever got along without it.

It's very handy.

REMUS: OK, I'm convinced. How do I start?

ROMULUS: This is where it gets sticky. It's free software, so there should be sources and binaries everywhere. It's hard to get binaries though. Steve Christensen's canonical http://www.sunfreeware.com for Solaris doesn't have it.

A NASA Web site has one as part of a 15 MB package. Binaries for other Unix variants can be even harder to get.

REMUS: So let's download and generate it ourselves.

ROMULUS: Good instinct. This is a graphics-related application, though, so I guess it's inevitable that the ride is a bumpy one. Here's what you do: pick up the latest distribution from ftp.X.org -- I've been using X11R6.4 for the last couple of years. In principle, this is the stage where you read the documentation, but X documentation is of the intimidating, makes-sense-if-you-already-know-it sort. You'll want to look at programs/Xserver/hw/vfb/Xvfb.man for yourself. The truth is, I've never seen anyone make progress generating Xvfb who isn't already very comfortable with C programming and X concepts.

In theory, you just have to do these three steps:

In config/cf/site.def (not config/cf/host.def, as some documentation instructs), insert the following two lines:

#define XVirtualFramebufferServer YES

#define BuildServer YES

make World

make

Xvfb seems to require the compilation of around eight hundred object files before a successful link is possible. In the best of circumstances, a correct generation of Xvfb seems to require up to an hour. My experience is that X never compiles cleanly out of the box, anyway. (See the Resources section, below, for a page that includes more details on building Xvfb.) I put aside a day whenever I need to move to a new Unix.

REMUS: That sounds awful.

ROMULUS: It is. The good news is that you only need to do it once. You can use Xvfb across a network, as you can with other servers. Configure one on your LAN, set its security policy, and you can dump all your unneeded DISPLAYs there.

REMUS: How do I start using the Xvfb I've made?

ROMULUS: Using it is less intimidating than building it, even though it has as many options and flags as you expect in an X application. It's easiest is to start with something simple, like Xvfb :1 -fbdir /tmp. That defines a virtual frame buffer mapped to a file in /tmp and assigns it a display number of one.

Test your virtual frame buffer by launching xterm -display :1. You can see what your X client application is doing with xwd -root -display :1 | xwud.

REMUS: Ah! Got it; that is worth the wait. Anything else I should know about Xvfb?

ROMULUS: Even though it's an old utility, Xvfb is attracting renewed attention from a new generation of Java programmers. Abstract window toolkit (AWT) implementations for Unix expect to be connected to a DISPLAY. People experimenting with image processors written in Java are finding that they can, for example, automate everything about an application, although they do need Xvfb or VNC for headless work. Jason Hunter's book on Java Servlet Programming nicely illustrates this with a discussion of just-in-time generation of images destined for the Web. While his footnote on DISPLAYs slightly mangles the facts, he correctly emphasizes to readers that they need to get the X configuration right before they can hope for results.

This might change in the future. The Java 2D API, part of the Java SDK 1.2, defines BufferedImages, which are useful in precisely this context of automating image processing. Until 1.2 is more widely available, though, there's a lot of clever server-side Java Web programming that needs Xvfb, or something very much like it. Even when there's a live DISPLAY available nearby, it can be nice to connect to Xvfb if only to prevent the automation tasks from using up the color palette available for viewed applications.

In a pinch, it's possible to get Xvfb running on an X11R5 system. That's even more painful than an X11R6 generation, though, and it's almost always easier just to upgrade to X11R6.

About the author

Cameron Laird and Kathryn Soraiz manage Phaseit, their own software consultancy, from just outside Houston, Texas.

Join the newsletter!

Error: Please check your email address.

More about NASAOpen GroupPhaseitTMP

Show Comments