# Specifying Order to Kill Nodes when Launch File is Killed

Is there any possible way to specify the order that the nodes initiated by a launch file are killed when the launch file as a whole is killed? I have a launch file that starts several nodes for the control of our robot. One of these is a node that takes care of the low level control of the robot. It is important that this node is the last one to be killed when shutting down the robot. From what I can tell, when a launch file is killed, the nodes are killed in a random order. Is there a way to make sure that this node is killed last? I know I can fix this by just having two separate launch files: one that launches this low level node and one that launches the rest and then make sure they are killed in the right order. I just was hoping there may be a way where I could do this all in one file to make it simpler to use. Thanks!

edit retag close merge delete

Sort by » oldest newest most voted

I know it has been a while, but I did end up finding a working (but not ideal) solution for my problem. As the other's mentioned, there is not a guaranteed way to enforce a shutdown order when killing a launch file. However, I was able to find a solution that worked for our needs. For any node that we needed killed before the low level controller, it was launched with the output='screen' and the launch-prefix="xterm-e" as shown in the example below.

<node name="pressure_commander" pkg='louie_control' type='control_to_pressure.py' output='screen' launch-prefix="xterm -e"/>

This makes an individual terminal for each of these nodes. You can kill these nodes individually with ctrl-c in its respective terminal. This way you can regulate the order that the nodes are killed. The disadvantage is that you have to individually kill each of these nodes. However, you do get the advantage of still being able to start them in one launch file.

more

roslaunch doesn't provide a guaranteed way to enforce startup or shutdown order.

If you want to make sure that some nodes start first or shut down last, you'll have to do as you suggest and put them in a separate launch file.

more

Could you describe your problem a bit more detailed? Is it really important that the driver-node is killed last or is it important that it not suddenly disappears when another node needs it, e.g. to stop a robot movement? A node is not suddenly terminated as soon as the launch file is closed, as you can see with this small node:

#! /usr/bin/python

import rospy
import signal
from time import sleep

rospy.init_node("killme")

def handler(sig_num, frame):
print "GOT SIGNAL", sig_num

signal.signal(signal.SIGTERM, handler)

while not rospy.is_shutdown():
rospy.sleep(1)

print "LAUNCH FILE WAS TERMINATED"

i = 0
while True:
print "i'm still alive", i
i+=1
sleep(1)


If you launch this and terminates the launch file, this happens:

core service [/rosout] found
process[killtest-1]: started with pid [9122]
[/killtest INFO 1484400429.490688]: i'm alive
[/killtest INFO 1484400430.491938]: i'm alive
[/killtest INFO 1484400431.493292]: i'm alive
[/killtest INFO 1484400432.494716]: i'm alive
^C[killtest-1] killing on exit
LAUNCH FILE WAS TERMINATED
i'm still alive 0
i'm still alive 1
i'm still alive 2
(...)
i'm still alive 13
i'm still alive 14
[killtest-1] escalating to SIGTERM
GOT SIGNAL 15
i'm still alive 15
i'm still alive 16
i'm still alive 17
[killtest-1] escalating to SIGKILL
Shutdown errors:
* process[killtest-1, pid 9122]: required SIGKILL. May still be running.
shutting down processing monitor...
... shutting down processing monitor complete
done


Your node first gets a gentle request to terminate (rospy.is_shutdown or ros::ok in C++), afterwards, you have around 15 sconds until ROS is getting a bit more direct by sending a SIGTERM which you still free to ignore, after another 3 seconds, ROS is killing you without mercy.

If the other nodes are terminating nicely after the rospy.is_shutdown, your driver node has 15 to 18 seconds to clean up, spawn other programs or just activate the emergency stop after the SIGTERM.

I know that this does not really answer your specific question but I think it could be usable for a solution to your problem.

more