Re: [Xen-devel] [xen-unstable test] 35257: regressions - FAIL

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel