I'm trying to track down some quirkiness with a Java application that misbehaves when launched via a startup script in /etc/init.d , but runs fine when you open a GUI terminal window and run it through /etc/init.d/myapp start. (The quirkiness involves a portion of the app that does some hacky handwaving with X.) Since the app runs fine when launched via a terminal window, I'm looking at how it's launched before I dive into (admittedly delicate and not my) source code.
The answer at this post gave me a clue that the Gnome terminal is running inside a window manager, which is somehow affecting (in a good way) the environment of the application I launch through a bash script. I was able to verify that launching the script through a tty terminal (ctrl-alt-f1 or via ssh) gives the same behavior as launching on startup.
My main question: What can I do to start this application when the computer starts, but have it act like it's been started under X? We've gone the script route up 'til now because it also needs to start a Java VM with certain parameters.
The follow up question (strictly to enhance my understanding): What is going on under the hood to make a script act differently when it's launched via something running in a window manager? Google has not enlightened me on this.
Best Answer
If your application needs an X server for some weird reason but doesn't do anything useful with it, give it a virtual X server. This is commonly done to run web browsers in automated test suites for web applications — nobody's looking at the screen but the web browser won't run without one.
Xvfb creates an X server that “displays” only to memory, not to anything viewable. It doesn't require any hardware or permissions.
The easiest way to use it is via the Debian
xvfb-runscript.If you don't have
xvfb-run, get it from one of many copies on the web or from the Debian package.