2010/6/10 Emre Erenoglu <erenoglu gmail com>:With absolute path as the initscript?
> On Thu, Jun 10, 2010 at 2:05 PM, Matthias Bolte
> <matthias bolte googlemail com> wrote:
>> 2010/6/10 Emre Erenoglu <erenoglu 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.
/usr/sbin/libvirtd --daemon --config /etc/libvirt/libvirtd.conf
Assuming LIBVIRTD_ARGS is empty in the initscript.
> 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:
> GUILE_LOAD_PATH=/usr/share/guile/1.8I asked about the environment variables and the commandline because
> CONFIG_PROTECT_MASK=/etc/texmf/web2c /etc/texmf/language.dat.d
> /etc/texmf/language.def.d /etc/texmf/updmap.d
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
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
problem manually. In that case you could just start libvirtd in GDB.
But getting a backtrace from a coredump will work too.