Is there an already existing issue for this?
Expected behavior
clean.py will clean up any orphaned resources in /dev/shm
Current behavior
clean.py does not clean up fast_datasharing* files that are created when data-sharing delivery is active (see DataSharingNotification.hpp)
Steps to reproduce
Setup up two processes with communication adhering to data sharing constraints. Forcibly kill them. Run clean.y.
Fast DDS version/commit
master, 2.14.3, etc.
Platform/Architecture
Ubuntu Focal 20.04 amd64
Transport layer
Shared Memory Transport (SHM), Data-sharing delivery
Additional context
It is unclear to me if the same mechanisms that are used cleaning the other orphaned files can be re-used (delete if file can be locked exclusively).
XML configuration file
No response
Relevant log output
No response
Network traffic capture
No response
Is there an already existing issue for this?
Expected behavior
clean.py will clean up any orphaned resources in /dev/shm
Current behavior
clean.py does not clean up fast_datasharing* files that are created when data-sharing delivery is active (see DataSharingNotification.hpp)
Steps to reproduce
Setup up two processes with communication adhering to data sharing constraints. Forcibly kill them. Run clean.y.
Fast DDS version/commit
master, 2.14.3, etc.
Platform/Architecture
Ubuntu Focal 20.04 amd64
Transport layer
Shared Memory Transport (SHM), Data-sharing delivery
Additional context
It is unclear to me if the same mechanisms that are used cleaning the other orphaned files can be re-used (delete if file can be locked exclusively).
XML configuration file
No response
Relevant log output
No response
Network traffic capture
No response