run - windows start command

How can a C/C++ program put itself into background? (7)

A wrapper script consisting of nothing but:

your_prog_or_script &

Will launch the target and exit immediately. You can add nohup to the beginning of that line so it will continue running if the shell is exited.

What's the best way for a running C or C++ program that's been launched from the command line to put itself into the background, equivalent to if the user had launched from the unix shell with '&' at the end of the command? (But the user didn't.) It's a GUI app and doesn't need any shell I/O, so there's no reason to tie up the shell after launch. But I want a shell command launch to be auto-backgrounded without the '&' (or on Windows).

Ideally, I want a solution that would work on any of Linux, OS X, and Windows. (Or separate solutions that I can select with #ifdef.) It's ok to assume that this should be done right at the beginning of execution, as opposed to somewhere in the middle.

One solution is to have the main program be a script that launches the real binary, carefully putting it into the background. But it seems unsatisfying to need these coupled shell/binary pairs.

Another solution is to immediately launch another executed version (with 'system' or CreateProcess), with the same command line arguments, but putting the child in the background and then having the parent exit. But this seems clunky compared to the process putting itself into background.

Edited after a few answers: Yes, a fork() (or system(), or CreateProcess on Windows) is one way to sort of do this, that I hinted at in my original question. But all of these solutions make a SECOND process that is backgrounded, and then terminate the original process. I was wondering if there was a way to put the EXISTING process into the background. One difference is that if the app was launched from a script that recorded its process id (perhaps for later killing or other purpose), the newly forked or created process will have a different id and so will not be controllable by any launching script, if you see what I'm getting at.

Edit #2:

fork() isn't a good solution for OS X, where the man page for 'fork' says that it's unsafe if certain frameworks or libraries are being used. I tried it, and my app complains loudly at runtime: "The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec()."

I was intrigued by daemon(), but when I tried it on OS X, it gave the same error message, so I assume that it's just a fancy wrapper for fork() and has the same restrictions.

Excuse the OS X centrism, it just happens to be the system in front of me at the moment. But I am indeed looking for a solution to all three platforms.

My advice: don't do this, at least not under Linux/UNIX.

GUI programs under Linux/UNIX traditionally do not auto-background themselves. While this may occasionally be annoying to newbies, it has a number of advantages:

  • Makes it easy to capture standard error in case of core dumps / other problems that need debugging.

  • Makes it easy for a shell script to run the program and wait until it's completed.

  • Makes it easy for a shell script to run the program in the background and get its process id:

    gui-program &
    # do something with $pid later, such as check if the program is still running

    If your program forks itself, this behavior will break.

"Scriptability" is useful in so many unexpected circumstances, even with GUI programs, that I would hesitate to explicitly break these behaviors.

Windows is another story. AFAIK, Windows programs automatically run in the background--even when invoked from a command shell--unless they explicitly request access to the command window.

The best way is probably to use QtService where the work of forking is taken care of for you.

However, if you want to continue to build your own, you should either background the application or run it via start-stop-daemon that comes with OpenRC or a similar utility for your distribution.

Also, make sure that you only link to the QtCore shared library. Although the application might be command line and never pull up the GUI, that doesn't mean that X isn't required in order for the application to run. For example, a set of unit tests:

$ ldd runTests  | grep Qt => /usr/lib/qt4/ (0x00007fd424de9000) => /usr/lib/qt4/ (0x00007fd424baa000) => /usr/lib/qt4/ (0x00007fd4240db000) => /usr/lib/qt4/ (0x00007fd422644000)

Because QtGui is present, all the X libraries are also brought in, although filtered from the above output.

The way it's typically done on Unix-like OSes is to fork() at the beginning and exit from the parent. This won't work on Windows, but is much more elegant than launching another process where forking exists.

start cmd 

on Windows,

cmd &

on *nux

Here substitute

cmd = java -jar JarFile.jar

On *nux the fg and bg commands are your friends as well ...

Run Qt application on startup as Linux daemon

Is your program a GUI application or does it work without GUI?

Why don't you just background it within the init script using &?

getting a program to return immediately at the command line so it's not tied to the shell that launched it

For an executable program (as opposed to a shell script), on Linux/Unix use fork() and exec() and then exit the parent process, which will return to the shell. For details see the man pages, or some page like