.lock file persists after shutting down control node

[c-staro]

Describe the bug
Hello,

after shutting down a ros2 node that uses ros2_control, the file "/tmp/ros2-control-controller-spawner.lock" persists and prevents other users from using ros2_control nodes. Admins can delete it, but regular users cannot.

To Reproduce
Steps to reproduce the behavior:

1. Start a ros2 node that executes ros2_control_node
2. Shut down the node via Ctrl+C --> tmp/ros2-control-controller-spawner.lock persists

Expected behavior
Cleanup of .lock file after shutting down, or handling it differently, so that it doesn't persist in /tmp.

Log
[spawner-4] Traceback (most recent call last):
[spawner-4] File "/opt/ros/jazzy/lib/python3.12/site-packages/controller_manager/spawner.py", line 185, in main
[spawner-4] lock.acquire(timeout=20)
[spawner-4] File "/usr/lib/python3/dist-packages/filelock/_api.py", line 255, in acquire
[spawner-4] self._acquire()
[spawner-4] File "/usr/lib/python3/dist-packages/filelock/_unix.py", line 39, in _acquire
[spawner-4] fd = os.open(self.lock_file, open_flags, self._context.mode)
[spawner-4] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[spawner-4] PermissionError: [Errno 13] Permission denied: '/tmp/ros2-control-controller-spawner.lock'
[spawner-4]
[spawner-4] During handling of the above exception, another exception occurred:
[spawner-4]
[spawner-4] Traceback (most recent call last):
[spawner-4] File "/opt/ros/jazzy/lib/controller_manager/spawner", line 33, in
[spawner-4] sys.exit(load_entry_point('controller-manager==4.29.0', 'console_scripts', 'spawner')())
[spawner-4] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[spawner-4] File "/opt/ros/jazzy/lib/python3.12/site-packages/controller_manager/spawner.py", line 405, in main
[spawner-4] node.destroy_node()
[spawner-4] ^^^^
[spawner-4] UnboundLocalError: cannot access local variable 'node' where it is not associated with a value
[ERROR] [spawner-4]: process has died [pid 435478, exit code 1, cmd '/opt/ros/jazzy/lib/controller_manager/spawner robotiq_gripper_controller -c /controller_manager --ros-args'].

Environment:

• OS: Ubuntu 24.04
• Version Jazzy

I cannot say for sure if changes to the environment have been performed by some users. Maybe the issue is on our side, but I cannot figure it out.

Thanks in advance for your suggestions :).

[saikishor]

Hello @c-staro!

Thank you for reporting the issue. Can you please add a print in the below statement and see if the release is being executed or not?. What version of python3-filelock is installed on your machine?

ros2_control/controller_manager/controller_manager/spawner.py

Line 387 in f97a2cb

lock.release()

Thank you

[c-staro]

Hello @saikishor,

Thanks for you quick reply. I did what you told me:

1. I am on python3-filelock version 3.13.1
2. My custom log-statements directly before and after lock.release() are executed
3. The BaseFileLock.release() method description states, that it doesn't automatically delete the .lock file

I also added:

os.remove(/tmp/ros2-control-controller-spawner.lock)

after the lock.release(), which solves my issue.

Do you see any problems in that? Thank you :).

[saikishor]

3. The BaseFileLock.release() method description states, that it doesn't automatically delete the .lock file

Do you know why? (or) What reason does it display?. We can add it, but I feel like this is an issue from the filelock side.

[c-staro]

This is the complete method declaration in filelock, class BaseFileLock:

 ```def release(self, force: bool = False) -> None:  # noqa: FBT001, FBT002
    """
    Releases the file lock. Please note, that the lock is only completely released, if the lock counter is 0. Also
    note, that the lock file itself is not automatically deleted.

    :param force: If true, the lock counter is ignored and the lock is released in every case/
    """
    if self.is_locked:
        self._context.lock_counter -= 1

        if self._context.lock_counter == 0 or force:
            lock_id, lock_filename = id(self), self.lock_file

            _LOGGER.debug("Attempting to release lock %s on %s", lock_id, lock_filename)
            self._release()
            self._context.lock_counter = 0
            _LOGGER.debug("Lock %s released on %s", lock_id, lock_filename)```

It seems like the problem is on the filelock side. Why should the lock file not be deleted automatically?

[saikishor]

@c-staro Can you report it in the filelock and refer this issue there. I would like to hear what they say.