What is the difference in running a process in background using start-stop-daemon with --background option and using with &?Which option is best and why?
If you use start-stop-daemon --background then start-stop-daemon will fork off a process to run in the background and then start-stop-daemon immediately exits. Among other things this means you can check the exit status of start-stop-daemon.
If you use start-stop-daemon & then the shell forks off a background process and runs start-stop-daemon in it. You won't be able to check its exit status as it won't actually exit (until the thing it runs exits).
In most cases start-stop-daemon --background is a better choice.
I prefer the & option for making a background job. However, on the occasions that I forget to include the &, I use the Ctrl-Z command to stop the job and then enter bg to move the stopped command into the background.
While I have not observed any difference in the approaches (with the exception that & can be used in a script). A colleague of mine was very pleased to find out about the Ctrl-Z option of suspending a job. He claimed that he had some tasks where that "worked better".
If you want to learn more about Ctrl-Z and bg, look for bash job control.
Related
I am trying to use start-stop-daemon to start a process that runs in the background. To my knowledge, start-stop-daemon is supposed to prevent a second process from being started if one is already running. The script I am running is rather simple for now:
#!/bin/sh
while true; do
date > /home/pi/test/test.txt
sleep 10
done
I am starting the script using start-stop-daemon --start -v -b -m --pidfile /var/run/test.pid --exec /home/pi/test/test.sh
I am able to successfully stop the script using start-stop-daemon --stop -v --pidfile /var/run/test.pid
However, if I run the start command twice, it will start two processes, instead of just one that I was expecting. Does the start command check the pid file before starting the process, or is there something else that needs to be done for that to happen?
The man page of start-stop-daemon contains a special warning on the usage of the --exec option with scripts.
-x, --exec executable
Check for processes that are instances of this executable. The executable
argument should be an absolute pathname. Note: this might not work as
intended with interpreted scripts, as the executable will point to the
interpreter.
When you run a script, the process that is actually launched is the interpreter noted in the shebang line of the script. This confuses the start-stop-daemon utility.
BTW, you can use the -t option to debug that kind of issues with start-stop-daemon.
I want to run jobs in the background so that I can logout from terminal once any job is started. I know two ways
1) run job and then press ctrl+z and then enter bg
mysqldump -uroot -p dbname > dbname.sql
2) using nohup to run job and then press ctrl+z and then enter bg
nohup mysqldump -u root -p dbname > dbname.sql 2>&1
I want to know the difference between above two commands and which one is best in which scenario.
Running your process as a job constrains your job to the current session. So if you run
$ start_running_job &
$ exit
The job will stop when you exit.
Pressing Control-Z has the same effect as the lines above.
Running nohup places the job so that it survives the end of the current session. So if you run
$ nohup start_running_job &
$ exit
The job will continue running.
I agree with answer provided...
"nohup" basically runs your command/script in back-end mode on server itself and it is not related to your current login session while putting "&" just puts the script in background and remains connected to your current login session. In any case you can use fg to bring back script/command.
Which is good for you, for this it depends how you are accessing your server and for how long your script is gonna take to complete. Say your script will take more amount of time and your current login session remains ideal it will close down and script will get killed if you have only given &. So much of the time just give nohup and don't worry it.
What is start-stop-daemon and how should it be used?
I am trying to automate a particular program to run. Whenever the system starts, the program should run. For that I am writing script in /etc/init.d/ location.
It is a program to manage the start and stop of system level background processes (daemons). You use it by passing in parameters (such as the pid file to create/check) and command arguments for the process you want to launch.
Then, you do one of two things:
start-stop-daemon -S [other arguments] something
start something, if something wasn't already running. If it was running, do nothing.
start-stop-daemon -K [other arguments] something
stop something. If something wasn't running, do nothing.
The man page provides more information on the various arguments. Typically a template is provided in /etc/init.d/ which has other commands for the init process that controls the running of background processes.
What does it mean?
start-stop-daemon --start --background -m --oknodo
--pidfile ${PIDFILE} --exec ${DAEMON} -- ${TARGETDIR}
--background = launch as a background process
-m = make a PID file. This is used when your process doesn't create its own PID file, and is used with --background
--oknodo = return 0, not 1 if no actions are taken by the daemon
--pidfile ${PIDFILE} = check whether the PID file has been created or not
--exec = make sure the processes are instances of this executable (in your case, DAEMON)
Copy the /etc/init.d/skeleton file (to e.g. /etc/init.d/rajeevdaemon or another good name), which is a shell script with a lot of comments, and edit it to suit your needs. Then add appropriate symlinks from e.g. /etc/rc2.d/S98rajeevdaemon and /etc/rc2.d/K98rajeevdaemon to it.
Read more about runlevels.
And recent (or future) Linux distributions are using more and more systemd
I am using upstart to start/stop/automatically restart daemons. One of the daemons forks 4 times. The upstart cookbook states that it only supports forking twice. Is there a workaround?
How it fails
If I try to use expect daemon or expect fork, upstart uses the pid of the second fork. When I try to stop the job, nobody responds to upstarts SIGKILL signal and it hangs until you exhaust the pid space and loop back around. It gets worse if you add respawn. Upstart thinks the job died and immediately starts another one.
Bug acknowledged by upstream
A bug has been entered for upstart. The solutions presented are stick with the old sysvinit, rewrite your daemon, or wait for a re-write. RHEL is close to 2 years behind the latest upstart package, so by the time the rewrite is released and we get updated the wait will probably be 4 years. The daemon is written by a subcontractor of a subcontractor of a contractor so it will not be fixed any time soon either.
I came up with an ugly hack to make this work. It works for my application on my system. YMMV.
start the application in the pre-start section
in the script section run a script that runs as long as the application runs. The pid of this script is what upstart will track.
in the post-stop section kill the application
example
env DAEMON=/usr/bin/forky-application
pre-start script
su -s /bin/sh -c "$DAEMON" joeuseraccount
end script
script
sleepWhileAppIsUp(){
while pidof $1 >/dev/null; do
sleep 1
done
}
sleepWhileAppIsUp $DAEMON
end script
post-stop script
if pidof $DAEMON;
then
kill `pidof $DAEMON`
#pkill $DAEMON # post-stop process (19300) terminated with status 1
fi
end script
a similar approach could be taken with pid files.
I have a bash script running in the background, and it executes in a loop every 5 seconds. This effects the commands that are being executed at the shell itself.
Is there a way, i can suspend the script execution until the shell is not executing other commands.
thanks
to stop the scipt you can use
kill -s STOP $PID
where $PID contains the process ID of the script. To start it again, you use
kill -s CONT $PID
Renice should help in such scenario.
Using renice you can decrease/increase the priority of the process.
Look man page for more detailed help.