On Thu, Jun 10, 2010 at 5:02 PM, Matthias Bolte <
matthias.bolte(a)googlemail.com> wrote:
2010/6/10 Emre Erenoglu <erenoglu(a)gmail.com>:
> On Thu, Jun 10, 2010 at 2:05 PM, Matthias Bolte
> <matthias.bolte(a)googlemail.com> wrote:
>>
>> 2010/6/10 Emre Erenoglu <erenoglu(a)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