Help with Xvfb, Eagle, and permissions on Ubuntu?


Trying to get Eagle working on a headless Ubuntu box using X virtual frame buffer. It sometimes kind of works, and there’s a general feeling that permissions are involved.

  1. xvfb-run -a /opt/eagle-7.3.0/bin/eagle -C’EXPORT IMAGE schematic.png 600; QUIT’ /var/www/dangercore/temp_upload/bp.sch
  2. xvfb-run -a /opt/eagle-7.3.0/bin/eagle -C’RUN /var/www/dangercore/eagle/ulp/bom.ulp; QUIT;’ /var/www/dangercore/temp_upload/bp.sch

Two commands need to be run. The first is a simple schematic/board image export, it kind of works when run by root or certain users. The second runs a ULP that dumps the BOM to a CSV file and it only works through a VNC (not using Xvfb).

Would like to hire a pro to get this going, but all advice is welcome.

Join the Conversation


  1. Hi Ian,

    I’m guessing it has something to do with the pid file (/var/run permissions). Maybe try storing it somewhere else with -f ?

    xvfb-run -f ~/ -a /opt/eagle-7.3.0/bin/eagle -C’RUN /var/www/dangercore/eagle/ulp/bom.ulp; QUIT;’ /var/www/dangercore/temp_upload/bp.sch

  2. Also, I just tested the same invocation as yours on my machine (CentOS 7 and Eagle 7.3.0) and it worked like a charm. The exported PNG contains the board, not the schematic and I don’t know why but other than that, launching Xvfb and Eagle inside it worked fine.

  3. … and fixed that as well: you must insert “EDIT .sch” or “EDIT .brd” before the “EXPORT” command to make sure the schematic/board get exported to the PNG file, otherwise it all depends on which window last gets focus.

  4. Thanks everyone. The log is Just typical stuff you’d see launching xvfb directly. I think I can export it to TCP when I checked on the log setting though. Going to try to connect to it and see whats happening.

    1. The references to “ListenTCP” in the xvfb-run manpage refer to instructing the X server to accept clients via TCP (in addition to the UNIX socket default). This means other clients could connect to the (virtual) server via the network and has nothing to do with VNC-like functionality. If you *want* VNC-like functionality, then start a VNC server (which creates an X server of its own) and run Eagle on *that* server.

      Or, if you really want to connect to an already running Xvfb to debug what’s wrong, then use x0vncserver as an X11 *client* (because that’s what it does: it’s meant for providing access to already running X servers) and then connect to it via VNC.

  5. I tried all of the above but still the same. I suspect permissions, but it doesn’t work as root either… I thought I could export the virtual frame buffer over tcp and view it but that doesn’t seem to be the case.

    1. It is for the dev site. It’s the biggest project we’ve ever done, and it is getting really really close to being ready to release. We are in the process of going live, I setup the backend rendering cluster this week and ran into this nightmare bug.

  6. Can you be more specific about what happens when it doesn’t work? E.g. is the BOM garbled, or just non-existent? Do you think eagle ran at all?

    What is the exit status from xvfb-run in the “failure” case? You can get this by running

    echo $?

    after the command completes. See the xvfb-run manpage for the meaning of different values.

    If you are in the mood to dig through prodigious amount of data, the answer to many “permission” problems can be found using strace. If you think the problem is in eagle then adding “strace” before the eagle command might be helpful. If you think the problem is in xvfb-run then add strace at the very beginning of the command line. Basically you are looking for something like “open” returning an error.

    1. It just hangs and I have to ctrl-c out. I will try strace.

      I have found a temporary solution so that we can keep developing: just run from a VNC desktop. I am not happy with that, but it works.

      This setup is a worker process pulling from a rabbitMQ message queue. The client process is better behaved and runs as a service in the background, is monitored with kill/restart etc.

      1. That’s most probably Eagle waiting on a confirmation dialog, nothing is actually broken. For example, running your command line (the first one) from above *twice* causes the second run to “hang” because Eagle is asking “Do you want to overwrite picture.png?”.

        Double check that the output folder is clean before running that OR rm -f the destination (to be sure) before you invoke Eagle.

      2. When it hangs, is the eagle process running?

        This is way out on a limb but, I just noticed in the manpage that xvfb-run defaults to 8 bit color. 8 bit color hasn’t really been a thing since the mid-90s. Perhaps there is some dusty corner of eagle that your script exercises that gets grumpy with a color depth it never expected. Try adding something like
        --server-args="-screen 0 1024x768x24"
        to the xvfb command line.

  7. It’s something weird about the way the schematic is being loaded. Solution is to specify the schematic on both the command line and in a edit command.

    eg. using a hacked bom.ulp I run this pointed at xvfb and it works well.

    /home/tom/bin/eagle-7.3.0/bin/eagle -C “edit $HOME/g/electronics/eagle/usb-isolator/usb-isolator.sch; run ./bom.ulp; quit” $HOME/g/electronics/eagle/usb-isolator/usb-isolator.sch

    ps. It’s a hack, but it works.

Leave a comment

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.