intermittent md5sum warning with no associated error message

I get this message off and on. There isn’t any error that I can see, so I’m unsure why this is complaining. Many other tasks in the playbook work fine, even in the same run.

Any idea what causes this?

TASK: [fix grub] **************************************************************

warning: md5sum command failed unusually, please report this to the list so it can be fixed

command: [u’(/usr/bin/md5sum /etc/default/grub 2>/dev/null)‘, u’(/sbin/md5sum -q /etc/default/grub 2>/dev/null)‘, u’(/usr/bin/digest -a md5 /etc/default/grub 2>/dev/null)‘, u’(/sbin/md5 -q /etc/default/grub 2>/dev/null)‘, u’(/usr/bin/md5 -n /etc/default/grub 2>/dev/null)‘, u’(/bin/md5 -q /etc/default/grub 2>/dev/null)‘, u’(/usr/bin/csum -h MD5 /etc/default/grub 2>/dev/null)']

What OS on the remote end?

– Michael

to share, just in case.

got the same occasionally running Ansible 1.4 from a F19 and through a very slow connection (through a VPN)

updated to 1.4.1 and did not reproduced it. Not sure how the update could have helped

BTW for the slow connection I will soon test ssh_alt (from Jerome Wagner) but not toonight**

Phil

It is Ubuntu 13.10 on both ends.

I started seeing this today too while doing some testing, and I believe it is due to the connection.

Here is what is at the end of the stderr when using -vvvv

debug2: channel 2: request exec confirm 1
debug3: mux_session_confirm: sending success reply
debug2: callback done
debug2: channel 2: open confirm rwindow 0 rmax 32768
debug1: mux_client_request_session: master session id: 2
debug2: channel_input_status_confirm: type 99 id 2
debug2: X11 forwarding request accepted on channel 2
debug2: channel_input_status_confirm: type 99 id 2
debug2: PTY allocation request accepted on channel 2
debug2: channel 2: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 2
debug2: exec request accepted on channel 2
debug2: channel 2: rcvd eof
debug2: channel 2: output open → drain
debug1: client_input_channel_req: channel 2 rtype exit-status reply 0
debug3: mux_exit_message: channel 2: exit message, evitval 0
debug1: client_input_channel_req: channel 2 rtype eow@openssh.com reply 0
debug2: channel 2: rcvd eow
debug2: channel 2: close_read
debug2: channel 2: input open → closed
debug2: channel 2: rcvd close
debug3: channel 2: will not send data after close
debug3: channel 2: will not send data after close
debug2: channel 2: obuf empty
debug2: channel 2: close_write
debug2: channel 2: output drain → closed
debug2: channel 2: send close
debug2: channel 2: is dead
debug2: channel 2: gc: notify user
debug3: mux_master_session_cleanup_cb: entering for channel 2
debug2: channel 1: rcvd close
debug2: channel 1: output open → drain
debug2: channel 1: close_read
debug2: channel 1: input open → closed
debug2: channel 2: gc: user detached
debug2: channel 2: is dead
debug2: channel 2: garbage collecting
debug1: channel 2: free: client-session, nchannels 3
debug3: channel 2: status: The following connections are open:
#2 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)

debug2: channel 1: obuf empty
debug2: channel 1: close_write
debug2: channel 1: output drain → closed
debug2: channel 1: is dead (local)
debug2: channel 1: gc: notify user
debug3: mux_master_control_cleanup_cb: entering for channel 1
debug2: channel 1: gc: user detached
debug2: channel 1: is dead (local)
debug2: channel 1: garbage collecting
debug1: channel 1: free: mux-control, nchannels 2
debug3: channel 1: status: The following connections are open:

debug3: mux_client_read_packet: read header failed: Broken pipe
debug2: Received exit status from master 0
Shared connection to X.X.X.X closed.
debug2: set_control_persist_exit_time: schedule exit in 900 seconds

Yes, I get the same error:

debug1: auto-mux: Trying existing master

debug2: fd 3 setting O_NONBLOCK

debug2: mux_client_hello_exchange: master version 4

debug3: mux_client_forwards: request forwardings: 0 local, 0 remote

debug3: mux_client_request_session: entering

debug3: mux_client_request_alive: entering

debug3: mux_client_request_alive: done pid = 8361

debug3: mux_client_request_session: session request sent

debug1: mux_client_request_session: master session id: 2

debug3: mux_client_read_packet: read header failed: Broken pipe

debug2: Received exit status from master 0

However, the connection is local and should be very reliable.

It could be something with the ssh mux client. I will try disabling that next.

I don’t seem to see the error passing “-c ssh” to disable the connection multiplexing.

Is there anything in my ssh config that could be causing this, or does ansible disable system/user defaults?