1

I have the following line in crontab.

@reboot /usr/bin/teamspeak3-server_linux-amd64/ts3server_minimal_runscript.sh

When I reboot, the script runs (i.e., my Teamspeak 3 server starts) in the background, but I was trying to find how I could stop it (I can't just ctrl+c the terminal since it's now running in the background). One forum post said to kill the process by using the command below.

ps -ef | grep -i XXXX:  to find your background running process

kill OID : kill your unnecessary process

By OID, I assumed he meant PID. However, when I tried to apply this to my scenario, I found three processes running, as shown below.

$ps -ef | grep ts3
server     889    586  0  22:33  ?       00:00:00 /bin/sh -c /usr/bin/teamspeak3-server_linux-amd64/ts3server_minimal_runscript.sh
server     890    889  0  22:33  ?       00:00:00 /usr/bin/teamspeak3-server_linux-amd64/ts3server_minimal_runscript.sh
server     903    890  0  22:33  ?       00:00:00 ./ts3server_linux_amd64

I am confused. Why are there three processes running? I was expecting just to see one script running (i.e., I imagined just the middle line would be there). I could kill all three and I guess it would stop my script, but I want to understand why there are three processes here and not one?

  • One thing you can try is to use pstree, if available, to see if the other processes got actually spawned by your script listed in cron. – Vikyboss Jun 28 '15 at 23:27
  • There are other, better answers on this probably, but I have a link to this one which demonstrates how easily find a process by PID with ps -opid= -C cmdname . You might also just use pgrep. – mikeserv Jun 28 '15 at 23:53
1

The first process is the shell running your script.

The second process is a shell sub-process of this script, possibly due to commands running inside parentheses, which causes the process to fork. An example is: "( date; cat )".

The third process is the binary of the actual server you want to run.

If you want to kill the server, kill the third process. This may then cause the sub-process to exit and then the main shell script to exit. However, the sub-process may be a shell loop, waiting for the server to die and then restarting it. So you may have to kill both the second and the third processes to stop it from respawning.

Most programs designed to run in the background have better ways for you to kill them. For example, the daemons started in /etc/init.d can usually be controlled by calling the script with "start", "stop", "restart", etc arguments. Your server may have a similar system.

  • 1
    Everything correct, but the second process is not a fork, it's the script itself running inside the sh instance spawned by cron. – kos Jun 29 '15 at 1:31
  • I don't think that comment is quite right either. All processes (except process 0) are the result of forks. Also, scripts in themselves don't get a process independent of the shell they are running in. So the first and second processes are both shells running a script. As shown by the difference in the command names in the ps output, the shell in the second process must have changed argv[0]. – Greg McFarlane Jun 30 '15 at 13:58
0

There's three process running because you're running 1 script and that script has commands written in it that run others apps:

  1. Bash (To run the script)
  2. The script itself.
  3. The app.

Inside the script:

root@onare:/home/onare# cat Downloads/TeamSpeak3-Client-linux_amd64/ts3client_runscript.sh 
#!/bin/bash

export KDEDIRS=
export KDEDIR=
export QTDIR=.
export QT_PLUGIN_PATH=.
export LD_LIBRARY_PATH=".:$LD_LIBRARY_PATH"

D1=$(readlink -f "$0")
D2=$(dirname "${D1}")
cd "${D2}"

if [ -e ts3client_linux_x86 ]; then
    ./ts3client_linux_x86 $@
else
    ./ts3client_linux_amd64 $@
fi

If you want to know all process running with grep, there's a command that you could use:

pgrep ts3 will promp all the PIDs that matches with *ts3*

Then run:

kill -9 $(pgrep ts3)

That will kill all the PIDs with ts3 running.

SS:

ps list

  • 1
    One small correction to "1. Bash (To run the script)". That's not bash, it's the POSIX /bin/sh (bourne) shell, which cron used to spawn the command. /bin/sh might be bash or a symlink to bash on some systems, but not so on others. – Celada Jun 29 '15 at 2:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.