@muthuArivoli I'd like to ask for some advice on migrating remote_launch.py. ROS2 is pretty annoying when it comes to killing nodes. The major issue right now is that terminating the pid of a ros2 run command doesn't kill the nodes that were started from the command as long as there's another instance of ros2 running. For instance:

  PID TTY          TIME CMD
    8 pts/0    00:00:00 entrypoint.sh
   10 pts/0    00:00:00 bash
10019 pts/10   00:00:33 python3
15351 pts/1    00:00:00 ros2
15352 pts/1    00:00:00 remote_launch
15375 pts/1    00:00:00 ros2
15376 pts/1    00:00:00 wrapper
15378 pts/1    00:00:00 data_server
15380 pts/1    00:00:00 guess_server
15382 pts/1    00:00:00 processing_serv
15413 pts/10   00:00:00 ps

Here, killing 15375 does not kill wrapper, data_server, guess_server, and processing_serv, all of which are nodes that were started with ros2 service call /start_node custom_msgs/srv/StartLaunch "{package: acoustics, file: acoustics.launch.py, is_launch_file: true, args: [sim:=true]}".

To get around this, my naive solution is to kill all PIDs larger than the "source" ros2 process (in this case 15375), stopping when we reach another ros2 process. This could also kill some processes that are unrelated, which isn't ideal. I'm thinking of creating an EOF-like process that is started after the original ros2 run or ros2 launch processes are started via a remote launch, which will signal that all of the nodes associated with the original ros2 process are deleted. Is this a reasonable solution? I'm not super familiar with how all of these things work, so I'd like to know if you have any other thoughts.

Instead of doing a SIGTERM, have you tried doing a SIGINT (I think use send_signal and signal.SIGINT)? I think that should work, they have different behavior.

If it doesn't, have you considered using the python interface that ros2 provides for launching stuff itself instead of using the cmd line? The package is located here: https://github.com/ros2/launch/tree/rolling/launch. The ros2launch command eventually calls this and you can sort of mock that. So, I think you might be able to create a LaunchDescription based on the parameters you are given from the service. You can then create a LaunchService and add that description to it, and the LaunchService appears to have run and shutdown. Though they don't seem to directly support threading, so not sure about that.

If those don't work, then yeah, go with whatever works. I'll give it a bit more thought.

Also, awesome work on this ROS2 stuff, I know it can be quite a headache. Excited to see this go through!

Instead of doing a SIGTERM, have you tried doing a SIGINT (I think use send_signal and signal.SIGINT)?

I recall trying this when I started a node via ros2 run and it didn't work. I'll give it a shot with ros2 launch and see if it behaves properly.

If it doesn't, have you considered using the python interface that ros2 provides for launching stuff itself instead of using the cmd line?

I did look at ros2launch briefly and thought that it was viable, although to my understanding it would limit us to only running launch files. I'll look into this more if SIGINT doesn't workout.

Good news, SIGINT works for launch files. Unfortunately, that means that nodes ran with ros2 run can't get stopped remotely for now, but I've written a TODO (and eventually an issue) to track this.