4

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.

Community
  • 1
Kathy
  • 143
  • 1
    This has (in all likelihood) nothing to do with window managers. Apparently your application is trying to reach an X server. How to solve your problem depends on why it's doing that. – Gilles 'SO- stop being evil' Nov 05 '13 at 23:30

2 Answers2

7

/etc/init.d scripts are non-interactive, non-login, and they don't try to access an X session because they are system wide services.1 System services aren't associated with any particular logged in user,2 but an X session always belongs to a logged in user.

If your application needs a GUI context to work, it shouldn't be a system service. You have not explained why it needs that or what it does, but likely you should be using ~/.xinitrc or the startup system of your Desktop Environment, not init.

1 X applications and logged in users may make use of a system service, but what you are talking about is the other way around.

2 Services are commonly associated with their own special user, but they are not logged in as such (and usually such users cannot be logged in).

Mike Diehn
  • 1,008
goldilocks
  • 87,661
  • 30
  • 204
  • 262
4

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-run script.

xvfb-run java MyWeirdApp

If you don't have xvfb-run, get it from one of many copies on the web or from the Debian package.

Gilles 'SO- stop being evil'
  • 829,060
  • Thanks, Gilles, this was the solution that worked for my app. (And is a whole lot less scary to give to end users than hacking around in ~/.xinitrc ) – Kathy Nov 06 '13 at 19:04