Determine which node is raising a ROS error

Question

I'm using Orocos with RTT-ROS integration for real-time control, and in the Orocos deployer I keep getting ROS errors like

[ERROR] [1529525996.660179901]: Unable to remove FD to epoll: Bad file descriptor
[ERROR] [1529525996.660213076]: Error closing socket [20]: [Bad file descriptor]

It comes up intermittently, and I want to know what node is giving that error so I can try to debug what's going on. Is there a way I can identify where the error is originating from?

---

Originally posted by adamconkey on ROS Answers with karma: 642 on 2018-06-20

Post score: 0

Answer 1

What I usually do is set console output formatting as described in answer 258929. That will print the node name as part of the error messages.

---

Originally posted by Thomas D with karma: 4347 on 2018-06-20

This answer was ACCEPTED on the original site

Post score: 2

---

Original comments

Comment by gvdhoorn on 2018-06-21:
@aconkey: I would recommend looking into what @Thomas D describes here. It'll be much more straightforward.

Comment by adamconkey on 2018-06-21:
That's great, I didn't know about this, thanks! Do you know if there's a way you can also format the time differently to be more compact? It takes up a lot of space and for console purposes I don't usually need that precise time tracking.

Comment by Thomas D on 2018-06-21:
I do not see any options in the documentation for truncating the time field.

Answer 2

I ended up figuring out one way just after posting this, but I'll be interested to know if there are other ways. The ROS log file associated with the session includes more information about where the log statement was issued, for example in my case the corresponding entry was

e668a370-7434-11e8-a202-f4f26d03b40d/rosout.log:1529464055.546618984 ERROR [/tmp/binarydeb/ros-kinetic-roscpp-1.12.13/src/libros/io.cpp:139(del_socket_from_watcher) [topics: /rosout, /lbr4/joint_states, /lbr4/pose] Unable to remove FD to epoll: No such file or directory

It actually shows exactly where the error was raised down to the line number, very helpful. I found this by navigating to the ROS log directory (in my case ~/.ros/log), and doing grep -r epoll, if you have the hash for your ROS session you can go directly to that, or do a more advanced grep if your error doesn't have identifying keywords.

---

Originally posted by adamconkey with karma: 642 on 2018-06-20

This answer was NOT ACCEPTED on the original site

Post score: 1

---

Original comments

Comment by AlessandroSaviolo on 2020-03-21:
Thanks! Solved my problem