Thanks, sorry, I was silly enough to have it missed before.
On 01/11/2017 09:32 AM, Daniel Belenky wrote: > Link to Jenkins > <http://jenkins.ovirt.org/view/experimental%20jobs/job/test-repo_ovirt_experimental_master/4648/artifact/exported-artifacts/basic_suite_master.sh-el7/exported-artifacts/> > > On Wed, Jan 11, 2017 at 10:26 AM, Francesco Romani <from...@redhat.com > <mailto:from...@redhat.com>> wrote: > > Hi all > > > On 01/11/2017 08:52 AM, Eyal Edri wrote: >> Adding Tomas from Virt. >> >> On Tue, Jan 10, 2017 at 10:54 AM, Piotr Kliczewski >> <piotr.kliczew...@gmail.com <mailto:piotr.kliczew...@gmail.com>> >> wrote: >> >> On Tue, Jan 10, 2017 at 9:29 AM, Daniel Belenky >> <dbele...@redhat.com <mailto:dbele...@redhat.com>> wrote: >> > Hi all, >> > >> > test-repo_ovirt_experimental_master (link to Jenkins) job >> failed on >> > basic_sanity scenario. >> > The job was triggered by >> https://gerrit.ovirt.org/#/c/69845/ >> <https://gerrit.ovirt.org/#/c/69845/> >> > >> > From looking at the logs, it seems that the reason is VDSM. >> > >> > In the VDSM log, i see the following error: >> > >> > 2017-01-09 16:47:41,331 ERROR (JsonRpc (StompReactor)) >> [vds.dispatcher] SSL >> > error receiving from <yajsonrpc.betterAsyncore.Dispatcher >> connected ('::1', >> > 34942, 0, 0) at 0x36b95f0>: unexpected eof (betterAsyncore:119) >> > > Daniel, could you please remind me the jenkins link? I see > something suspicious on the Vdsm log. > Most notably, Vdsm received SIGTERM. Is this expected and part of > the test? > >> > >> >> This issue means that the client closed connection while vdsm was >> replying. It can happen at any time >> when the client is not nice with the connection. As you can >> see the >> client connected locally '::1'. >> >> > >> > Also, when looking at the MOM logs, I see the the following: >> > >> > 2017-01-09 16:43:39,508 - mom.vdsmInterface - ERROR - >> Cannot connect to >> > VDSM! [Errno 111] Connection refused >> > >> >> Looking at the log at this time vdsm had no open socket. >> >> > > Correct, but IIRC we have a race on startup - that's the reason > why MOM retries to connect. After the new try, MOM seems to behave > correctly: > > 2017-01-09 16:44:05,672 - mom.RPCServer - INFO - ping() > 2017-01-09 16:44:05,673 - mom.RPCServer - INFO - getStatistics() > > -- > Francesco Romani > Red Hat Engineering Virtualization R & D > IRC: fromani > > > > > -- > /Daniel Belenky > / > /RHV DevOps > / > /Red Hat Israel > / -- Francesco Romani Red Hat Engineering Virtualization R & D IRC: fromani
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel