[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-users] libxl -> libxenstore dependency
- To: xen-users@xxxxxxxxxxxxxxxxxxx
- From: Josef Liška <jl@xxxxxx>
- Date: Wed, 10 Nov 2010 15:13:48 +0100
- Delivery-date: Wed, 10 Nov 2010 06:14:54 -0800
- List-id: Xen user discussion <xen-users.lists.xensource.com>
Hi,
the bug is filled here:
http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1686
Boris: libvirt stops working after cca 330 connections, trying 8-10
connections is not enough. Another way is to look at lsof and cound
pipes, e.g. lsof | grep libvirt | grep pipe | wc -l. If the number
grows, you have leaking libxenstore.
S pozdravem
Josef Liška
CHL | system care
Telefon: +420.272048055
Fax: +420.272048064
Mobil: +420.776026526 denně 9:00 - 17:30
Jabber: jl@xxxxxx
https://www.chl.cz/
Dne 10.11.2010 14:49, Josef Liška napsal(a):
Hi list,
I have attached trivial one line patch close_pipes.patch.
It seems to me that call to close_fds_free(h) in function
xs_daemon_close was lost by mistake.
Function xs_daemon_destroy_postfork calls this function properly.
I'll try to file a bug now.
Best regards
Josef Liška
CHL | system care
Telefon: +420.272048055
Fax: +420.272048064
Mobil: +420.776026526 denně 9:00 - 17:30
Jabber: jl@xxxxxx
https://www.chl.cz/
Perhaps not directly relevant to your bug, but I found a similar problem with
our custom-build Debian package for xen-4.0.1:
libxl doesn't link to libxenstore itself, but if you want to use libxl with
any program, you have to link libxenstore as well, as libxl uses the function
from libxenstore. This confuses dpkg-shlibdeps, which resolves the
shared-library-dependencies on a per-symbol basis:
* xs_daemon_destroy_postfork() is only available from >= 4.0.0~rc4.
* libxl uses it, but isn't directly linked to libxenstore, so dpkg-shlibdeps
isn't able to determin, that libxenstore from >= 4.0.0~rc4 is needed during
runtime. Instead it just declares a dependency on libxenstore.
* Any program (currently only xl) using libxl might crash during runtime as
soon as xs_daemon_destroy_postfork() while an old libxenstore is installed.
Something like the following pseudo-patch solved the problem by already
linking libxl to libxenstore:
@ xen-4.0.1/tools/libxl/Makefile:62
libxenlight.so.$(MAJOR).$(MINOR): $(LIBXL_OBJS)
- $(CC) $(CFLAGS) $(LDFLAGS) -Wl,$(SONAME_LDFLAG) -Wl,libxenlight.so.
$(MAJOR) $(SHLIB_CFLAGS) -o $@ $^
+ $(CC) $(CFLAGS) $(LDFLAGS) $(LDFLAGS_libxenstore) -Wl,
$(SONAME_LDFLAG) -Wl,libxenlight.so.$(MAJOR) $(SHLIB_CFLAGS) -o $@ $^
Alternatively incrementing the minior version of libxenstore would have been a
good idea, since a new function was added.
Sincerely
Philipp Hahn
!DSPAM:2,4cdaa395114764967921375!
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
!DSPAM:2,4cdaa395114764967921375!
|
Attachment:
jl.vcf
Description: Vcard
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|