Revision history [back]

Does "rosbag record -j" do its compression in the background after ROS shutdown?

I have a Python node that invokes rosbag record -j to record some topics.

• On shutdown, rosbag returns.

• At that point I want to run a script that uploads the bag from the robot to a server. That will take a while, and I don't want to delay shutdown so long.

• The node, which is now shutting down, runs the script in the background under a different process group using the Linux setsid command (link to code).

• Even when I run the script that way, it sometimes stops immediately without copying the expected bag file, which is expected to match $prefix_*.bag. Running the same command afterwards by hand works fine. • Delaying the script from starting seems to make it work more often. The length of delay needed appears to increase with the size of the bag. So, I wonder if rosbag record -j is running its compression step in the background after ROS shutdown causes it to return. That would explain what I see: the $prefix_*.bag file does not exist until compression finishes.

Does "rosbag record -j" do its compression in the background after ROS shutdown?

I have a Python node that invokes rosbag record -j to record some topics.

• On shutdown, rosbag returns.

• At that point I want to run a script that uploads the bag from the robot to a server. That will take a while, and I don't want to delay shutdown so long.

• The node, which is now shutting down, runs the script in the background under a different process group using the Linux setsid command (link to code).

• Even when I run the script that way, it sometimes stops immediately without copying the expected bag file, which is expected to match $prefix_*.bag. Running the same command afterwards by hand works fine. • Delaying the script from starting seems to make it work more often. The length of delay needed appears to increase with the size of the bag. So, I wonder if rosbag record -j is running its compression step in the background after ROS shutdown causes it to return. That would explain what I see: the $prefix_*.bag file does not exist until compression finishes.