On Thu, Jun 10, 2010 at 5:02 PM, Matthias Bolte < matthias.bo...@googlemail.com> wrote:
> 2010/6/10 Emre Erenoglu <ereno...@gmail.com>: > > On Thu, Jun 10, 2010 at 2:05 PM, Matthias Bolte > > <matthias.bo...@googlemail.com> wrote: > >> > >> 2010/6/10 Emre Erenoglu <ereno...@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
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list