I am the author of an application which runs in the background and is always up (hopefully). I have a requirement for my application to start user applications, such as an editor, a spreadsheet, a game, or any application which the operator (who is remote) wants to start. I am looking for the best way to do this. I was told early on that if a background process starts an app with a visual display, the display will not show up because daemons are disconnected from stdout, however, I have tried it and the various apps I have tried to start seem to work fine and display fine, except as noted below. I am developing on a system using the Gnome desktop although my clients use every conceivable sort of desktop and Linux flavor . My application is written in C++ and in my early tests I am starting these appplications like this:

system("<app name> &");

In my early tests, I am just trying to start a couple of games because they are simple easy to find examples of apps with graphics. I am basically doing this:

system("/usr/bin/blackjack");
sleep(2);
system("/usr/bin/bomber");

etc.

I have found that it works pretty well on the Fedora, Ubuntu, and CentOS virtuals I have, except that some of the games complain that they can't need GConf information. It works less well on my openSUSE virtual. On openSUSE, sometimes it works, but other times the games return various errors such as:

GLib-GIO:EROR:gdbusconnection.c.......assertion failed.......

or

link g4300 hasn't been detected!

In one case, it gave an error when I exited the first game started before the second one started. In all cases, I am starting the apps with an ampersand to put them in the background. In general, on openSUSE, it worked part of the time and returned a random error the rest of the time.

MY QUESTION IS THIS - is simply using a system command, e.g.

system("<app name>" &);

an acceptable way to do this, or is there a more clever approach which would work better?

Thanks in advance for your expertise.

Brandon

Using system() really ain't the best way do what you're trying to do.

What you want to do a fork() and exec() (which is what the shell does -- you type a command and hit the enter key and the shell forks-and-execs the command).

What you want to do is use the exec family of functions (see the exec manual page for the advantages and disadvantages of each) rather than system() (see the system manual page for a discussion of the disadvantages of system()).

Hope this helps some.

1 members found this post helpful.

Generally, using system() is only necessary if the process you are launching requires a shell. Otherwise, using fork() + exec() is more efficient. You may need to set up environment variables in your parent process prior to launching the child process(es), in order for them to properly locate resources they require, such as libraries ($LD_LIBRARY_PATH), configuration files (application-specific variables), X server ($DISPLAY), and other applications ($PATH).

--- rod.

Thank you.

The applications started might be anything, including ones that displayed graphics. One additional thing here that I am confused about is the case where multiple users are logged into the Linux PC. These applications I have referred to above are started on the PC in question by a remote user at a management console. He contacts a daemon running on the PC in question, and it is this daemon on the PC which actually starts the application. The remote manager might want to start an app on the PC such that only one of the users logged in could see it. I know that this has something to do with X and display numbers, but that is about as much as I know. How might a program run on a PC such that only one of the people logged in would actually get the display?

Brandon

Your terminology is a bit confusing, as the use of the term 'remote' depends on point of view, and to all of us reading this, it is all remote. In my reply, I assume 'remote' to be hosts that are not running the 'daemon application'.

At any rate, your scenario has some complicated issues to deal with. When you say 'users are logged into the Linux PC', do you mean an actual login, or is this just a network connection to your daemon process? If the former, how do they login; ssh, telnet, other?

As I understand your architecture, the daemon process launches child processes, as requested by users by using some manner of communication with that daemon process. As such, those child processes will be owned by the owner of the daemon process, and will inherit such things as UID, GID, and environment from that ancestry. This has implications for launching X client applications, as the remotely attached users' X servers will need to be identified to the X applications. Your application will need to set $DISPLAY to point to the remote user's X server. How to do this will depend on the nature of the attachment made through the initial 'login'. Moreover, the X server at the remote users' site may need to be configured to accept connections from an X client that is owned by a different user.

It would be useful for you to learn a little about the nature the the X-Windows client/server architecture. To many people, the client & server relationship seems backward, initially. This is probably because we tend to think of servers as something remote, whereas X servers tend to run on a host that is locally situated (so we can see them and interact with them). The X server receives commands from X client applications, and serves those commands by rendering imagery on a screen, and also serves pointer and keyboard input back to the client applications. In order for applications launched by the daemon process to connect with X servers on the remote hosts, the applications will need to be told how to find the X remote server. This is done by passing the 'display=' argument, or by setting $DISPLAY appropriately prior to launching the child process. Your 'remote manager' application will need to somehow convey this information to the daemon process as part of the request to launch the application.

--- rod.

Thank your for spending so much time on discussing my issue with me. To clarify my architecture a little, I have written a daemon process which takes commands from a single remote manager console. One of the commands is to start an application for a user. I had never considered that the user might be anyone other than a single person using the Linux PC that the daemon is on, but that possibility was brought to my attention today. I do not know how the multiple users would be logged into the PC (they don't log in to my daeomon or anything like that), but the concern seems reasonable since Linux systems can have multiple users connected at the same time in various ways. Not being a system administrator I don't know quite how that works. The hypothetical scenario would be that the person at the manager console is somehow aware of the multiple users logged into the dameon's PC and wishes to start an app of some sort which only one of the users can see. It sounds like the daemon will have to receive enough information from the management console to set an XWindows display variable.

Okay, then, that sounds like the easy scenario. Any other scenario will be somewhere between difficult and impossible.

--- rod.