qcr/services-config

Pre and Post Start Command Addition

Closed this issue · 3 comments

Similar to the previous robot-brinup.serivce, it would be good to add the pre and post commands (from systemd) into the tool for creating these types of services. Main use case is for the panda, which requires the pre and post commands to unlock/lock the brakes.

Would simply having the following optional keys within the service configuration yaml file be valid:

pre_command: <user value>
post_command: <user_value>

These would then enter the systemd service file like so:

ExecStartPre=/bin/bash -c "<value of pre_command>"
ExecStop=/bin/bash -c "<value of post_command>'"

@DasGuna

Should the source_env, catkin_ws and append_to_pythonpath values be included within the ExecStartPre and ExecStop components or not?

For example, if I have a services configuration file like so:

source_env: /etc/qcr/qcr-env.bash
catkin_ws: /opt/ros/noetic/setup.bash
append_to_pythonpath: /my/python/path
services:
- name: my-sensor
  description: my sensor launch  
  parent_service: ros-sensors.service
  command: my-command
  pre_command: my-pre-command
  post_command: my-post-command
  run_on_boot: true

Which service file should it create? (Only part of the created service file is shown for clarity)

Option 1:

[Service]
ExecStartPre=/bin/bash -c "source /etc/qcr/qcr-env.bash && export PYTHONPATH=/my/python/path:$PYTHONPATH && source /opt/ros/noetic/setup.bash && my-pre-command"
ExecStart=/bin/bash -c "source /etc/qcr/qcr-env.bash && export PYTHONPATH=/my/python/path:$PYTHONPATH && source /opt/ros/noetic/setup.bash && my-command"
ExecStop=/bin/bash -c "source /etc/qcr/qcr-env.bash && export PYTHONPATH=/my/python/path:$PYTHONPATH && source /opt/ros/noetic/setup.bash && my-post-command"

Option 2:

[Service]
ExecStartPre=/bin/bash -c "my-pre-command"
ExecStart=/bin/bash -c "source /etc/qcr/qcr-env.bash && export PYTHONPATH=/my/python/path:$PYTHONPATH && source /opt/ros/noetic/setup.bash && my-command"
ExecStop=/bin/bash -c "my-post-command"

I would go with Option 1 (add to all) just so it doesn't limit functionality (if a pre or post run needs something from a workspace or env file)