1

Possible Duplicate:
How can I close a terminal without killing the command running in it?

I'm using Debian for my Server.

I just installed MediaCore, which works well.

Now I want to have it always started and want to ask, how it'd be possible to start it as a service or in the background.

I know how to start but then the shell is useless as long as the program runs.

So how can I run it silently, as I run services/daemons?

2 Answers2

3

You have a couple options.

First, you can launch it in screen and then Ctrl-A out of the screen after it launches. You can later reattach to the screen with a screen -RR {screen number}; you can figure out the screen number with a screen -ls. (If you only have one active screen a simple screen -RR will reattach).

Second, you can launch it from the shell and background it by appending an & after the command. However, you also want to redirect stdout and stderr to appropriate files so the shell isn't interspersing output of the command with your shell. I think something like

$ command > command.stdout 2> command.stderr &

is what you are looking for.

I've never used MediaCore so I don't know what it outputs. If you just want to capture all output to a file whether from stdout or stderr, this will work

$ command &> command.output &

However, in the long run, since you are using Debian, the right thing to do is add an init script for it (as @user606723 mentioned). There is a skeleton script in /etc/init.d that would be a good starting point.

LawrenceC
  • 10,992
  • Note that if you read the screen man file, you can execute screen inside of a script with a certain executable and still add that into init.d. I've done this before because I wanted it automatically executing but I also wanted to be able to interact with it later if needed. (Non-OSS program, not very flexible). – user606723 Jul 22 '11 at 21:06
0

You may run your program with 'screen' or use 'hohup' for detaching from terminal.

nohup my_app 2>/dev/null 2>&1 & 

OR

screen -d -m my_app 
  • You should also consider adding it to init.d (or similar). And, you don't necessarily need to &> /dev/null, it might be useful to put that towards some sort of log file. You might also consider making a special user just for the program. – user606723 Jul 22 '11 at 13:58