You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Working to reproduce #72 I've been bringing up and down the daemon a lot. I ran into this sequence where the daemon failed to stop but didn't report as such.
Possibly we need similar behavior to #71 on stop too?
C:\Users\OSRF\Downloads\ardent_opensplice\ros2-windows>ros2 daemon status
The daemon is running
C:\Users\OSRF\Downloads\ardent_opensplice\ros2-windows>ros2 node list
C:\Users\OSRF\Downloads\ardent_opensplice\ros2-windows>ros2 node list
C:\Users\OSRF\Downloads\ardent_opensplice\ros2-windows>ros2 daemon stop
The daemon has been stopped
C:\Users\OSRF\Downloads\ardent_opensplice\ros2-windows>ros2 daemon status
The daemon is running
C:\Users\OSRF\Downloads\ardent_opensplice\ros2-windows>ros2 daemon status
The daemon is running
C:\Users\OSRF\Downloads\ardent_opensplice\ros2-windows>ros2 daemon stop
The daemon has been stopped
C:\Users\OSRF\Downloads\ardent_opensplice\ros2-windows>ros2 daemon status
The daemon is not running
C:\Users\OSRF\Downloads\ardent_opensplice\ros2-windows>
The text was updated successfully, but these errors were encountered:
We can't implement the same workaround as in #71 for the starting phase because the shutdown is being triggered by a request. While that request is being triggered the server can't be shutdown from within the request so the request can't "wait" until the server is shut down. Also server is currently not handling any further requests after the shutdown has been requested.
Even with the following command sequences I never got it to report that daemon is still running after stopping it:
ros2 daemon start && ros2 daemon status
ros2 daemon stop && ros2 daemon status
There is still a race between the server shutting down and checking the status because the status check only checks if the port is in use or not. Without additional overhead (instead of checking the port actually sending a request and waiting for a reply) I don't see a way to resolve this.
Hence I will close this ticket as "wontfix". Please feel free to comment if you think the status check should do the more expensive check instead or have a different proposal.
* Refactor Node parse() function.
Make use of ignore support in ExecuteProcess.
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
* Avoid creative Node argument renaming.
Signed-off-by: Michel Hidalgo <michel@ekumenlabs.com>
Working to reproduce #72 I've been bringing up and down the daemon a lot. I ran into this sequence where the daemon failed to stop but didn't report as such.
Possibly we need similar behavior to #71 on stop too?
The text was updated successfully, but these errors were encountered: