From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [xen-unstable test] 35257: regressions - FAIL Date: Tue, 3 Mar 2015 10:37:49 +0000 Message-ID: <1425379069.24959.76.camel@citrix.com> References: <1425030149.14641.119.camel@citrix.com> <20150227104829.GA29195@zion.uk.xensource.com> <1425042785.14641.188.camel@citrix.com> <54F0D7FE.4080203@suse.com> <21748.17914.317136.91748@mariner.uk.xensource.com> <1425296288.1886.37.camel@citrix.com> <54F4A516.3020201@suse.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <54F4A516.3020201@suse.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jim Fehlig Cc: Wei Liu , xen-devel@lists.xensource.com, Ian Jackson List-Id: xen-devel@lists.xenproject.org On Mon, 2015-03-02 at 10:59 -0700, Jim Fehlig wrote: > Ian Campbell wrote: > > On Mon, 2015-03-02 at 11:14 +0000, Ian Jackson wrote: > > > >> Jim Fehlig writes ("Re: [Xen-devel] [xen-unstable test] 35257: regressions - FAIL"): > >> ... > >> > >>> In my experience, if ERROR is insufficient, INFO and WARNING don't > >>> help. DEBUG is needed. > >>> > >> Where does virtd's stderr go ? That is where any assertion failure > >> message would be written. > >> > > > > /dev/null from the looks of the code: > > http://libvirt.org/git/?p=libvirt.git;a=blob;f=daemon/libvirtd.c;h=2366d63cd3c70f75df5af82d2c241df163293eab;hb=HEAD#l174 > > > > When daemonized, yes :-/. You would need to run libvirtd without the > '-d' option to see the assert. Which would run in the foreground, I think? So we would need to handle daemonisation some other way? Probably best to avoid that I think. > Or collect a core as Ian suggested. This would seem to be a generically useful thing to do, as well as helping here. I think it could be achieved by ts-host-install editing /etc/sysctl.conf to set sys.kernel.core_pattern to something (perhaps a new dir under /var/). http://man7.org/linux/man-pages/man5/core.5.html describes the substitutions and says it is there since 2.4.21 and 2.6. Some sort of ulimit frobbing might also be needed I suppose. Then ts-logs-capture would pick up anything which appeared in the directory which is in core_pattern. Or perhaps a new test step ts-core-check could be added which fails the test if anything is found? Ian, if you think this makes sense I could add to my TODO. Ian.