On Thu, Jun 10, 2010 at 5:02 PM, Matthias Bolte <matthias.bolte@xxxxxxxxxxxxxx> wrote:
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.
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.
2010/6/10 Emre Erenoglu <erenoglu@xxxxxxxxx>:With absolute path as the initscript?
> On Thu, Jun 10, 2010 at 2:05 PM, Matthias Bolte
> <matthias.bolte@xxxxxxxxxxxxxx> wrote:
>>
>> 2010/6/10 Emre Erenoglu <erenoglu@xxxxxxxxx>:
>> > 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.
/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.
> LS_COLORS= ...
>>
>> - 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
> GUILE_LOAD_PATH=/usr/share/guile/1.8I asked about the environment variables and the commandline because
> 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
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.
Getting a backtrace would be simpler if you could reproduce the
>> 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.
>
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
Thanks a lot for your support Matthias!
Emre
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list