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? On Tuesday, December 3, 2013 4:13:03 PM UTC-8, [email protected] wrote: > > 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. > > > On Tuesday, December 3, 2013 3:47:30 PM UTC-8, Matt Martz wrote: >> >> 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 [email protected] 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 >> -- >> Matt Martz >> [email protected] >> >> On December 3, 2013 at 5:09:43 PM, [email protected] ( >> [email protected]) wrote: >> >> It is Ubuntu 13.10 on both ends. >> >> On Monday, December 2, 2013 7:42:40 PM UTC-8, Michael DeHaan wrote: >>> >>> What OS on the remote end? >>> >>> -- Michael >>> >>> On Dec 2, 2013, at 6:53 PM, "[email protected]" < >>> [email protected]> wrote: >>> >>> 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)'] >>> >>> ---- >>> >>> output: {'stdout': '', 'stderr': '', 'rc': 0} >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Ansible Project" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Ansible Project" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
