Crash on headless servers: clipboard X11 connection failure

[Rxflex]

When running jdbrowser on a headless Linux server over SSH (no GUI, no X11), the application crashes with the following panic:

The application panicked (crashed).
Message:  called `Result::unwrap()` on an `Err` value: Unknown { .. } - "Unknown error while interacting with the clipboard: X11 server connection timed out because it was unreachable"
Location: src/ui/talbe_view.rs:141

📍 Cause

The code at src/ui/talbe_view.rs:141 unconditionally calls .unwrap() on Clipboard::new():

let clipboard = Clipboard::new().unwrap(); // Panics on headless systems

This fails when there's no X11 environment available (e.g., server-only systems or SSH sessions without X forwarding).

✅ Suggested Fix

Gracefully handle clipboard initialization failures:

let clipboard = match Clipboard::new() {
    Ok(cb) => Some(cb),
    Err(e) => {
        eprintln!("Clipboard init error: {e}");
        None
    }
};

Later code should check if let Some(cb) = clipboard before usage.

💡 Optional

Add support for disabling clipboard via environment variable, e.g.:

if std::env::var("DISABLE_CLIPBOARD").is_ok() {
    clipboard = None;
}

And run with:

DISABLE_CLIPBOARD=1 jdbrowser

🧪 Environment

• OS: Ubuntu 22.04 Server
• Access: SSH without GUI/X11
• Version: latest

Thanks!

[Jkeyuk]

Thank you. I will check this ASAP.

[supporter-1161]

Running X11-dependent Applications in Docker on a Headless Server

Problem: A Rust application requires X11 to function, but the server (Debian 12) lacks a GUI environment. Launching it results in:

The application panicked: ... clipboard: X11 server connection timed out ...

Solution: Use a Docker container with a virtual X server (Xvfb) to emulate a graphical environment.

1. Problem Diagnosis

• Error indicates no available X11 server
• Server shouldn't have (and doesn't need) a GUI
• Application uses X11 for clipboard operations

2. Solution: Docker + Xvfb

Advantages:

• No GUI installation required on server
• Dependency isolation
• Lightweight solution (~100 MB image)
• Supports multiple concurrent instances

3. Dockerfile

FROM debian:bookworm-slim

# Install dependencies
RUN apt-get update && apt-get install -y \
    xvfb \
    x11-utils \
    mesa-utils \
    libgl1-mesa-dri \
    libx11-6 \
    libxcb1 \
    libxrandr2 \
    libxinerama1 \
    libxcursor1 \
    libxi6 \
    libxext6 \
    libsqlite3-0 \
    ca-certificates \
    dbus

# Copy application
COPY ./target/release/jdbrowser /usr/local/bin/jdbrowser

# Copy startup script
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh"]
CMD ["jdbrowser", "-f", "/data"]

4. Startup Script (entrypoint.sh)

#!/bin/sh
export DISPLAY=:99
Xvfb $DISPLAY -screen 0 1024x768x24 >/dev/null 2>&1 &
sleep 1
exec "$@"

5. Building the Image

docker build -t x11-app-runner .

6. Running the Application

Basic method:

docker run -it --rm \
  -v /path/to/databases:/data \
  x11-app-runner \
  xvfb-run -a jdbrowser -f /data/specific_file.sqlite3

Optimized launcher script (run_app.sh):

#!/bin/bash
# run_app.sh: Automated container launch

if [ $# -eq 0 ]; then
  echo "Usage: $0 <path-to-sqlite-file>"
  exit 1
fi

DB_FILE="$1"
DIR_PATH=$(dirname "$DB_FILE")
FILE_NAME=$(basename "$DB_FILE")

docker run -it --rm \
  -v "$DIR_PATH":/data \
  x11-app-runner \
  xvfb-run -a jdbrowser -f "/data/$FILE_NAME"

Usage:

chmod +x run_app.sh
./run_app.sh /home/user/db/message.sqlite3

7. Implementation Key Points

1. Xvfb (X Virtual Frame Buffer):

   • Emulates X11 without physical display
   • -a flag auto-selects available DISPLAY
   • Runs in background

2. Volume Mounting:

   • Mount directories instead of individual files
   • Use $(dirname) and $(basename) for path handling

3. Minimal Dependencies:

   • Only essential X11 libraries
   • Excluding dev packages reduces image size

4. Automation:

   • Wrapper script simplifies Docker commands
   • Supports arbitrary number of files

8. Common Issues & Solutions

Problem	Solution
libsqlite3.so.0 not found	Add libsqlite3-0 to dependencies
X11 connection rejected	Increase startup delay: xvfb-run -a -w 3 ...
File access denied	Verify permissions: chmod a+r /path/to/files
Clipboard errors	Install xclip: apt-get install xclip

9. Alternative Approaches

1. Wayland instead of X11:

   RUN apt-get install -y libwayland-client0 libwayland-cursor0
   CMD ["jdbrowser", "--backend", "wayland"]

2. Static Application Build:

   • Use musl for full static linking
   • scratch or alpine-based images

3. Disable X11 Features:

   • Modify application code to work without clipboard
   • Use dummy driver

10. Solution Advantages

• Isolation: Dependencies contained in container
• Portability: Works on any Docker host
• Security: No access to real X server
• Resource Efficiency: Minimal memory usage (~50 MB/container)
• Scalability: Parallel execution of multiple instances

11. Production Recommendations

1. Use Docker Compose for management:

services:
  dbviewer:
    image: x11-app-runner
    volumes:
      - ./dbs:/data
    command: xvfb-run -a jdbrowser -f /data/prod_db.sqlite3

2. Add health checks:

HEALTHCHECK --interval=30s --timeout=3s \
  CMD pgrep -x jdbrowser >/dev/null || exit 1

3. Multi-architecture builds:

docker buildx build --platform linux/amd64 -t x11-app-runner .

This guide preserves all critical steps and can be adapted for running any X11-dependent applications in headless environments.

[Rxflex]

Running X11-dependent Applications in Docker on a Headless Server

Problem: A Rust application requires X11 to function, but the server (Debian 12) lacks a GUI environment. Launching it results in:

The application panicked: ... clipboard: X11 server connection timed out ...

Solution: Use a Docker container with a virtual X server (Xvfb) to emulate a graphical environment.

1. Problem Diagnosis

* Error indicates no available X11 server

* Server shouldn't have (and doesn't need) a GUI

* Application uses X11 for clipboard operations

2. Solution: Docker + Xvfb

Advantages:

* No GUI installation required on server

* Dependency isolation

* Lightweight solution (~100 MB image)

* Supports multiple concurrent instances

3. Dockerfile

FROM debian:bookworm-slim

Install dependencies

RUN apt-get update && apt-get install -y
xvfb
x11-utils
mesa-utils
libgl1-mesa-dri
libx11-6
libxcb1
libxrandr2
libxinerama1
libxcursor1
libxi6
libxext6
libsqlite3-0
ca-certificates
dbus

Copy application

COPY ./target/release/jdbrowser /usr/local/bin/jdbrowser

Copy startup script

COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

ENTRYPOINT ["/entrypoint.sh"]
CMD ["jdbrowser", "-f", "/data"]

4. Startup Script (entrypoint.sh)

#!/bin/sh
export DISPLAY=:99
Xvfb $DISPLAY -screen 0 1024x768x24 >/dev/null 2>&1 &
sleep 1
exec "$@"

5. Building the Image

docker build -t x11-app-runner .

6. Running the Application

Basic method:

docker run -it --rm
-v /path/to/databases:/data
x11-app-runner
xvfb-run -a jdbrowser -f /data/specific_file.sqlite3

Optimized launcher script (run_app.sh):

#!/bin/bash

run_app.sh: Automated container launch

if [ $# -eq 0 ]; then
echo "Usage: $0 "
exit 1
fi

DB_FILE="$1"
DIR_PATH=$(dirname "$DB_FILE")
FILE_NAME=$(basename "$DB_FILE")

docker run -it --rm
-v "$DIR_PATH":/data
x11-app-runner
xvfb-run -a jdbrowser -f "/data/$FILE_NAME"

Usage:

chmod +x run_app.sh
./run_app.sh /home/user/db/message.sqlite3

7. Implementation Key Points

1. **Xvfb (X Virtual Frame Buffer)**:
   
   * Emulates X11 without physical display
   * `-a` flag auto-selects available DISPLAY
   * Runs in background

2. **Volume Mounting**:
   
   * Mount directories instead of individual files
   * Use `$(dirname)` and `$(basename)` for path handling

3. **Minimal Dependencies**:
   
   * Only essential X11 libraries
   * Excluding dev packages reduces image size

4. **Automation**:
   
   * Wrapper script simplifies Docker commands
   * Supports arbitrary number of files

8. Common Issues & Solutions

Problem Solution
libsqlite3.so.0 not found Add libsqlite3-0 to dependencies
X11 connection rejected Increase startup delay: xvfb-run -a -w 3 ...
File access denied Verify permissions: chmod a+r /path/to/files
Clipboard errors Install xclip: apt-get install xclip

9. Alternative Approaches

1. **Wayland instead of X11**:
   RUN apt-get install -y libwayland-client0 libwayland-cursor0
   CMD ["jdbrowser", "--backend", "wayland"]

2. **Static Application Build**:
   
   * Use `musl` for full static linking
   * `scratch` or `alpine`-based images

3. **Disable X11 Features**:
   
   * Modify application code to work without clipboard
   * Use `dummy` driver

10. Solution Advantages

* **Isolation**: Dependencies contained in container

* **Portability**: Works on any Docker host

* **Security**: No access to real X server

* **Resource Efficiency**: Minimal memory usage (~50 MB/container)

* **Scalability**: Parallel execution of multiple instances

11. Production Recommendations

1. Use Docker Compose for management:

services:
dbviewer:
image: x11-app-runner
volumes:
- ./dbs:/data
command: xvfb-run -a jdbrowser -f /data/prod_db.sqlite3

2. Add health checks:

HEALTHCHECK --interval=30s --timeout=3s
CMD pgrep -x jdbrowser >/dev/null || exit 1

3. Multi-architecture builds:

docker buildx build --platform linux/amd64 -t x11-app-runner .

This guide preserves all critical steps and can be adapted for running any X11-dependent applications in headless environments.

Bro, but this is a very huge crutch, why wrap something in docker that should work natively?

[awarebayes]

Same issue, unusable in terminal

[supporter-1161]

Bro, but this is a very huge crutch, why wrap something in docker that should work natively?
I'm not a Rust developer, I just needed to get this software up and running. I know it's a crutch. But the crutch is working.

[abdellatif-temsamani]

Same issue