1

[EDIT] I changed SIGINT to SIGTERM in whole question.

I have a script which runs subproccess script which starts jboss.

#!/bin/sh
....
start_jboss.sh &
trap 'kill -SIGTERM 0' EXIT HUP TERM INT
....

I want to send SIGTERM signal to jboss when my script was killed, terminated or interrupted. But above code does not terminate JBoss. KILL signal kills JBoss (following code) but JBoss does not release H2 database lock. It is important in my case to release H2 lock so I have to use SIGTERM signal.

#!/bin/sh
....
start_jboss.sh &
trap 'kill -9 0' EXIT HUP TERM INT
....

My JBoss uses port 8080 so following command gives me a JBoss pid:

sudo netstat -lnpt | grep 8080

If I execute following command:

 kill -SIGTERM jboss_pid_from_netstat_command

then JBoss is interrupted and releases H2 database lock.

How to modify my trap action to send SIGTERM singal to JBoss? I don't know why SIGKILL works and SIGTERM does not work.

[EDIT] I changed SIGINT to SIGTERM in whole question.

EDIT

JBoss start script (standalone.sh) starts JBoss in foreground process if LAUNCH_JBOSS_IN_BACKGROUND is not set and starts JBoss in background process if this variable is set. So I set this variable in my script. Following scripts works properly then:

#!/bin/sh
....
export LAUNCH_JBOSS_IN_BACKGORUND=a
standalone.sh &
trap 'kill -SIGTERM 0' EXIT HUP TERM INT
....


#!/bin/sh
....
export LAUNCH_JBOSS_IN_BACKGORUND=a
standalone.sh &
trap 'kill -SIGTERM $(jobs -pr)' EXIT HUP TERM INT
....


#!/bin/sh
....
export LAUNCH_JBOSS_IN_BACKGORUND=a
standalone.sh &
jboss_script_id=$!
trap 'kill -SIGTERM $jboss_script_id' EXIT HUP TERM INT
....

I still have no idea why following code does not work. I work on Centos with bash. I tested it on Ubuntu with dash and following codes work but core dump warning is thrown.

(not work)

#!/bin/sh
....
standalone.sh &
trap 'kill -SIGTERM 0' EXIT HUP TERM INT
....

or (not work)

#!/bin/sh
....
standalone.sh &
trap 'kill -SIGTERM $(jobs -pr)' EXIT HUP TERM INT
....

or (not work)

#!/bin/sh
    ....
    standalone.sh &
    jboss_script_id=$!
    trap 'kill -SIGTERM $jboss_script_id' EXIT HUP TERM INT
    ....

2 Answers 2

1

It is probable that the jboss server has a termination handler in the case that it has been interrupted during processing of I/O (e.g. writing to the database). The TERM and INT signals may be handled to ensure that the database is not corrupted when the signal arrives and the process is busy doing I/O.

With SIGKILL there is no grace - the process is executed ruthlessly no matter what it is doing. There is no handler permitted for a SIGKILL signal. This can be an important reason to avoid kill -9 for process termination unless there is no alternative.

For some reason killing the entire process group interferes with correct termination and removal of database lock. Try kill the jboss server like this - NOTE you may need to extend the kill command to ensure all the children of the script also die (I don't know your entire script).

trap 'kill -SIGTERM $(jobs -pr)' EXIT HUP TERM INT

Which will kill jboss as the jobs command will return the background processes running from the shell (i.e. the jboss process in your case).

1
  • I tested your suggestion and it does not work. It is very strange. I work on Centos 7 with bash. But I tested it also on Ubuntu with dash and your soultion and my work there but core dump is thrown. If LAUNCH_JBOSS_IN_BACKGROUND variable is set then JBoss proccess runs in background and your and my solution work on Centos and Ubuntu.
    – Mariusz
    Jan 19, 2015 at 8:38
0

I had the same issue.

If you want to kill your running valgrind process, Ctrl+C will not going to do it.

Since valgrind handles some signals, we may send it a signal so it can do something. If you don't know the list of signals you can check it by saying (on terminal):

your_user_name:Directory$ kill -l

This command will list all available signals for you.

  1. Run your program with valgrind (Example: valgrind --tool=memcheck ./prog)

  2. Check valgrind PID on the left side. Example: ==938== Memcheck, a memory error detector

  3. Open another terminal window: kill -SIGTRAP 938

This should work for you.

If it does not work for you, you may try sending some other signals, and i'm sure you find one that interrupts valgrind and it still prints out the report.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .