As one new to the forum, I believe I have a "simple" question for the community today

The scenario in question involves the launch of a bash script at boot (via upstart, init, or similar). This script takes care of some assorted rudimentary functions; and remains at work in those capacities until well past user login. All good so far.

Post-login, the script forks a program (pick anything from a lowly terminal to a browser) which includes a GUI. At this point, the music just stops; and the program so launched simply folds up and dies before even hitting the screen. The script itself goes merrily on...

We all know about tackling such problems from the desktop environment via autostart, ~/.xinitrc, or similar kludges. But what about situations in which one would prefer to have a consolidated boot-time solution which can simply serve all logins without hassle?

In sum, what might be a reasonable tack to effectively allow a GUI-based app to launch from a boot-level script?

Thanks again --

X Virtual Frame Buffer (xvfb) is often used for launching background X windows based GUIs.

Doing search in Google reveals many hits for using this with init scripts:
https://www.google.com/search?q=xvfb...utf-8&oe=utf-8

I haven't used it in an init script myself but we do use it here for starting various Oracle GUIs in the background.

@MensaWater:

Thanks for the tip.

Xvfb up and running @ runlevel 2 with the following parameters:All verified as up via Task Manager on the Desktop side...

However, the issue persists: Should Xvfb be called in conjunction with an offending program directly, or is there some other subtle point which presently eludes?

Ideas? Syntax???

Thanks again --

Did you specify the "-display :99" variable on start of the GUI so it will use the display you assigned in xvfb?

@MensaWater:

Trying that now; but I just wrapped up an experiment with a Python/GTK script which I equipped withjust after the opening declarations (no dice).

Back in a few with the verdict on

Placed -display :99 in everything except Linus' shorts: Still no luck. Again, everything in the chain works perfectly if it's called from the terminal by hand.

Started from boot, no dice!

Xvfb up and healthy...

Here's something which might reasonably be expected to tick over for a dry run @ the terminal:...but, of course, only this will workSo, how would we go about pointing zenity to display=:99 or, possibly, what might we do with the Xvfb line to cooperate with the likes of this?

(willing to try anything reasonable at this juncture)

If started from terminal by hand...

Are you talking about the initial launch script or something you do in the GUI after it is launched? If the former your issue may be you're missing some environment variable in the boot script that you have when you do the initial launch. This is fairly common with background scripts like those run in init or cron. The most common one is PATH but their could be others you're relying on depending on the application. The PATH variable you have at command line usually has a lot more than the minimal one background tools will give you so you need to include it in the script itself.

Type "env" after login to see what variables you have set then determine if you need to add any to the startup.

@MensaWater:

Thanks for the info and tips. In the end nothing seemed to help...

So, I switched tack to add a (forked) launchline to the /etc/profile script which is reputed to serve well as a cross-login solution in cron settings. It worked; but in doing so I had to segment my approach to cover both root- and GUI-level functional requirements. Not as simple as blasting through and pointing something to the correct display, but effective in the end.

This is really strange behavior. I've heard the problem likened to having "gum stuck to your shoe" which somehow prohibits GUI launches throughout any chain from bootup scripting, even if a connected (or forked) downstream process is launched well after login.

Is this an integral part of the Linux security model, or just another "quirk" which we need to just live with???

At any rate, thanks again; and have a great day