Bug #49
closedlttng destroy: sendmsg: Bad file descriptor
0%
Description
root@thinkos:/home/compudj/work/lttng-modules# lttng create
Session auto-20120215-221107 created.
Traces will be written in /root/lttng-traces/auto-20120215-221107
root@thinkos:/home/compudj/work/lttng-modules# lttng enable-event -k -a
All kernel events are enabled in channel channel0
root@thinkos:/home/compudj/work/lttng-modules# lttng start
Tracing started for session auto-20120215-221107
root@thinkos:/home/compudj/work/lttng-modules# lttng stop
Tracing stopped for session auto-20120215-221107
root@thinkos:/home/compudj/work/lttng-modules# lttng destroy
Session auto-20120215-221107 destroyed at /root
but the lttng-sessiond -vvv gives:
DEBUG1: Destroying session auto-20120215-221107 [in session_destroy() at session.c:155]
DEBUG1: Updating kernel poll set [in update_kernel_poll() at main.c:671]
DEBUG1: Thread kernel polling on 2 fds [in thread_manage_kernel() at main.c:828]
DEBUG1: Sending response (size: 16, retcode: Success) [in thread_manage_clients() at main.c:3672]
sendmsg: Bad file descriptor
Error: Failed to send data back to client
DEBUG1: Clean command context structure [in clean_command_ctx() at main.c:457]
DEBUG1: Accepting client command ... [in thread_manage_clients() at main.c:3573]
upon destroy
Updated by David Goulet almost 13 years ago
- Status changed from New to Invalid
This is very strange. This error only happens if the send response from the session daemon to the lttng client fails. However, lttng cli shows "Session auto-20120215-221107 destroyed at /root" meaning that the reply from the session daemon was indeed received and processed...
I think you may have hit a kernel "brain freeze" because this situation is impossible. In any case, the log shows us that the session was indeed destroyed and the session daemon is still OK to accept command so this error does not break anything.
I'll flag this bug as Invalid for now but if you can reproduce this at will, please report it fast.