[libvirt] Segfault in libvirtd when run as a service

Emre Erenoglu erenoglu at gmail.com
Thu Jun 10 17:57:15 UTC 2010


On Thu, Jun 10, 2010 at 5:02 PM, Matthias Bolte <
matthias.bolte at googlemail.com> wrote:

> 2010/6/10 Emre Erenoglu <erenoglu at gmail.com>:
> > On Thu, Jun 10, 2010 at 2:05 PM, Matthias Bolte
> > <matthias.bolte at googlemail.com> wrote:
> >>
> >> 2010/6/10 Emre Erenoglu <erenoglu at gmail.com>:
> >> > Dear list,
> >> >
> >> > I'm trying to package libvirt 0.8.1 for our distribution, Pardus
> 2009.2.
> >> > libvirt is installed perfectly normal, and libvirtd runs OK when I
> start
> >> > it
> >> > in a console using root account.
> >> >
> >> > However, when I start libvirtd as a service, with the same parameters,
> >> > through the normal service startup functions, it segfaults.
> >> >
> >> > The services in Pardus 2009.2 are started using a management backend
> >> > which
> >> > works with python and service start/stop scripts are python based.
> >> >
> >> > For libvirt, it's the following:
> >> >
> http://svn.pardus.org.tr/pardus/playground/ozan/libvirt/comar/service.py
> >> >
> >> > Whatever I did, I couldn't find why libvirt is crashing. It works
> normal
> >> > when I run it from console with exactly the same parameters. Here's an
> >> > earlier syslog section ending with the crash:
> >> >
> >>
> >> There are some things to consider:
> >>
> >> - Did you use the exact same commandline as the initscript when
> >> testing manually?
> >
> > Yes. In fact, the only parameter passed is the --daemon parameter with
> > current configuration.
>
> With absolute path as the initscript?
>
>  /usr/sbin/libvirtd --daemon --config /etc/libvirt/libvirtd.conf
>
> Assuming LIBVIRTD_ARGS is empty in the initscript.
>

Yes, if you check the script service.py, you'll see. We start libvirtd with
the absolute path and exactly the above parameters. The conf file itself is
the default one.

>
> >>
> >> - Did you make sure to use the same environment variable configuration
> >> when starting libvirtd manually, compared to the initscript?
> >
> > Here's the environment of the root user, I will try to find out the
> > environment of the service script:
> >
> >
> >
> MANPATH=/usr/local/share/man:/usr/share/man:/opt/sun-jre/man:/usr/kde/4/share/man
> > HOSTNAME=EMRE
> > SHELL=/bin/bash
> > TERM=linux
> >
> XDG_SESSION_COOKIE=3d6ade2bb28141896f3212d64bf41670-1276174999.886063-1263776093
> > HUSHLOGIN=FALSE
> > LC_ALL=en_US.UTF-8
> > USER=root
> > LS_COLORS= ...
> > GUILE_LOAD_PATH=/usr/share/guile/1.8
> > MC_ENV=/usr/share/mc/bin/mc.sh
> > PAGER=/usr/bin/less
> > CONFIG_PROTECT_MASK=/etc/texmf/web2c /etc/texmf/language.dat.d
> > /etc/texmf/language.def.d /etc/texmf/updmap.d
> >
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin:/opt/sun-jre/bin:/usr/kde/4/sbin:/usr/kde/4/bin
>
> I asked about the environment variables and the commandline because
> you have /usr/local/sbin befreo /usr/bin in PATH. So you might have
> two libvirtds installed, one in /usr/local/sbin and one in /usr/sbin.
>

> The initscript explicitly starts the one in /usr/sbin. If you just
> start libvirtd manually without an absolute path then you'll start the
> one in /usr/local/sbin. This might explain why you cannot reproduce
> the segfault manually, but it doesn't explain why the segfault
> happens.
>

There's no other installation of libvirt in the system. I can also reproduce
the same thing in all Pardus machines, so I believe it's something in
libvirt not doing well with something else in our service init mechanisms.

>
> >> Could you provide a GDB backtrace of the segfault? The syslog entry only
> >> says that it crashed in libc, that's not enough information to
> >> debug the segfault.
> >
> > Unfortunately, I can't find a related core file in the system. In fact,
> core
> > file is not generated. I'll also try to fix this out and come back to the
> > list.
> >
>
> Getting a backtrace would be simpler if you could reproduce the
> problem manually. In that case you could just start libvirtd in GDB.
> But getting a backtrace from a coredump will work too.
>
I can't reproduce the segfault when I run it manually. It only happens when
it's run from this python script. I will try to initialize gdb inside the
script and connect remotely to the gdb session, but it's getting a bit over
my debugging capabilities :)  For example, I don't know how to assign the
symbols and source code etc from the package build directory to gdb.

Thanks a lot for your support Matthias!

Emre
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20100610/b547804d/attachment-0001.htm>


More information about the libvir-list mailing list