xvfb

Xvfb [:display_number] [-screen screen_number widthxheightxdepth] [options...]

:display_number
    Specifies the display number (e.g., :99) for the virtual X server. This number is used to set the DISPLAY environment variable for clients.

-screen screen_number widthxheightxdepth
    Defines the characteristics of a virtual screen. screen_number is usually 0. width, height define resolution, and depth is the color depth (e.g., 1024x768x24).

-fbdir directory
    Specifies a directory where framebuffer backing store files will be created. Not commonly used unless specific persistence is needed.

-pixmapdir directory
    Specifies a directory for backing store files for pixmaps. Similar to -fbdir.

-cc class
    Changes the default visual class for the virtual screen (e.g., TrueColor, DirectColor).

-dpi dpi
    Sets the dots per inch (DPI) value for the virtual screen. Affects font rendering and scaling.

-logfile file
    Redirects server output messages and errors to the specified log file.

-nolisten tcp
    Prevents the X server from listening for TCP connections, enhancing security by limiting access to local Unix domain sockets only.

-auth file
    Specifies an X authority file to use for access control. Essential for secure client connections.

-ac
    Disables access control, allowing any host to connect. Use with extreme caution as it introduces significant security risks.

-terminate
    Causes Xvfb to exit automatically after all clients have disconnected from the server.

-s script
    Runs a shell script after the server has initialized. Useful for setting up the environment or running initial commands.

Xvfb, which stands for X Virtual Framebuffer, is an X server that performs all graphical operations in memory without displaying anything on a physical screen. It acts as a complete, albeit virtual, X display. This makes it invaluable for environments where a graphical interface is required but no physical display or input devices are present, such as:

Automated Testing: Running GUI-based test suites (e.g., Selenium, Cypress) on continuous integration servers without a visible browser window.
Server-Side Applications: Executing applications that require an X server to render graphics or interact with an X environment, but don't need user interaction.
Screen Scraping and Rendering: Generating screenshots or processing graphical output from X applications programmatically.

Xvfb creates a virtual screen buffer in RAM, allowing applications to draw to it as if it were a real display. It provides a full X server environment, complete with input events and rendering capabilities, making it a robust solution for headless graphical operations.

While powerful, Xvfb has some considerations:
No Visual Output: By design, it does not display anything on a physical monitor. Debugging graphical issues can be challenging without visual feedback.
Memory Consumption: Large screen resolutions and color depths can consume significant amounts of RAM, as the entire framebuffer is stored in memory.
Security: Running Xvfb without proper access control (e.g., using -ac or not using -nolisten tcp) can expose the virtual display to unauthorized access, especially in networked environments.
Resource Management: It's important to manage the lifecycle of Xvfb instances, particularly in automated scripts, to avoid accumulating zombie processes or consuming excessive resources.

A typical workflow for using Xvfb involves:
1. Starting Xvfb: Xvfb :99 -screen 0 1024x768x24 &
(This starts Xvfb on display number :99 with a screen resolution of 1024x768 at 24-bit color depth, and runs it in the background.)
2. Setting DISPLAY: export DISPLAY=:99
(This tells subsequent X clients to connect to the virtual display created by Xvfb.)
3. Running Applications: Execute your GUI application or test suite (e.g., firefox, google-chrome, Selenium tests).
4. Cleaning Up: After use, terminate the Xvfb process (e.g., kill <PID_of_Xvfb>). Some tools like xvfb-run automate this process.

The DISPLAY environment variable is crucial for any X client to know which X server to connect to. When using Xvfb, you must set this variable to match the display number you assigned to your Xvfb instance (e.g., export DISPLAY=:99). Without this, X applications will attempt to connect to the default display, which might be a physical one or none at all.

Many distributions provide a helper script named xvfb-run. This script simplifies using Xvfb by automatically starting an Xvfb instance, setting the DISPLAY environment variable, running the specified command, and then cleaning up the Xvfb process when the command exits. It's often preferred for one-off commands or simpler scripts. Example: xvfb-run firefox

The concept of a virtual framebuffer for the X Window System emerged in the mid-1990s as part of efforts to provide X server capabilities in environments without direct graphical hardware or for automated testing. Xvfb was developed by David Wiggins and others, becoming a component of the XFree86 project, and subsequently integrated into the X.Org Server, the open-source implementation of the X Window System. Its development was driven by the increasing need for headless operation in server environments, particularly for applications requiring graphical rendering (like web browsers for testing or server-side rendering tools) without the overhead or requirement of a physical display. It has since become a standard and indispensable tool in continuous integration/delivery (CI/CD) pipelines and cloud deployments.

X(7), xinit(1), startx(1), xdpyinfo(1), xhost(1), DISPLAY(7)