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]<javascript:>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] <javascript:> > > On December 3, 2013 at 5:09:43 PM, [email protected]<javascript:>( > [email protected] <javascript:>) 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] <javascript:>. > 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.
