Hi list,
I am hunting a bug between libvirt and xen, which seems to appeared
after xen-4.0.1rc3.
The problem is a "pipe leak". Each connection to libvirt leaves 3 open
files:
libvirtd 14758 root 18u unix
0xffff88002600ed00 351779 socket
libvirtd 14758 root 19r FIFO
0,8 351781 pipe
libvirtd 14758 root 20w FIFO
0,8 351781 pipe
Steps to reproduce:
1. install xen-4.0.1 and libvirt 0.7.6+
2. for i in `seq 1 1000`; do virsh -c xen://daman.vmin.cz list; done
if fails on "Too many open files"
After libvirt restart, works fine for cca 300 connections
I have not seen this with xen-3. Since libvirt links libxenstore:
libxenstore.so.3.0 => /usr/lib/libxenstore.so.3.0
(0x00007f8845fea000)
and since I have a box with xen-4.0.1rc3 which seems to work well, I
have tried to replace libxenstore.so.3.0 with one from older box. Voila,
no "pipe leak".
Now I would like to look into sources and try to find which change
introduced this behavior. Unfortunatelly,
I am unable to clone git repo:
los:/mnt/y# git clone http://xenbits.xen.org/xen-4.0-testing.hg
Initialized empty Git repository in /mnt/y/xen-4.0-testing.hg/.git/
error: File 0000000000000000000000000000000000000000
(http://xenbits.xen.org/xen-4.0-testing.hg/objects/00/00000000000000000000000000000000000000)
corrupt
Getting pack list for http://xenbits.xen.org/xen-4.0-testing.hg
Getting alternates list for http://xenbits.xen.org/xen-4.0-testing.hg
Also look at <a href="http://www.selenic.com/mercurial/">mercur
Getting pack list for <a
href="http://www.selenic.com/mercurial/">mercur
error: Protocol <a href="http not supported or disabled in libcurl
error: Unable to find 0000000000000000000000000000000000000000 under
http://xenbits.xen.org/xen-4.0-testing.hg
Cannot obtain needed object 0000000000000000000000000000000000000000
fatal: Fetch failed.
Does anyone have a fresh copy of xen repo? I''d like to try "git
bisect".
--
S pozdravem
Josef Liška
CHL | system care
Telefon: +420.272048055
Fax: +420.272048064
Mobil: +420.776026526 denně 9:00 - 17:30
Jabber: jl@chl.cz
https://www.chl.cz/
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
My fault, it is not git but mercurial. Mercurial does not seem to have bisect feature. I''ll try converting http://hivelogic.com/articles/converting-from-mercurial-to-git S pozdravem Josef Liška CHL | system care Telefon: +420.272048055 Fax: +420.272048064 Mobil: +420.776026526 denně 9:00 - 17:30 Jabber: jl@chl.cz https://www.chl.cz/ Dne 9.11.2010 15:00, Josef Liška napsal(a):> Hi list, > I am hunting a bug between libvirt and xen, which seems to appeared > after xen-4.0.1rc3. > > The problem is a "pipe leak". Each connection to libvirt leaves 3 open > files: > libvirtd 14758 root 18u unix > 0xffff88002600ed00 351779 socket > libvirtd 14758 root 19r FIFO > 0,8 351781 pipe > libvirtd 14758 root 20w FIFO > 0,8 351781 pipe > > Steps to reproduce: > 1. install xen-4.0.1 and libvirt 0.7.6+ > 2. for i in `seq 1 1000`; do virsh -c xen://daman.vmin.cz list; done > if fails on "Too many open files" > > After libvirt restart, works fine for cca 300 connections > > > I have not seen this with xen-3. Since libvirt links libxenstore: > libxenstore.so.3.0 => /usr/lib/libxenstore.so.3.0 > (0x00007f8845fea000) > and since I have a box with xen-4.0.1rc3 which seems to work well, I > have tried to replace libxenstore.so.3.0 with one from older box. > Voila, no "pipe leak". > > Now I would like to look into sources and try to find which change > introduced this behavior. Unfortunatelly, > I am unable to clone git repo: > > > los:/mnt/y# git clone http://xenbits.xen.org/xen-4.0-testing.hg > Initialized empty Git repository in /mnt/y/xen-4.0-testing.hg/.git/ > error: File 0000000000000000000000000000000000000000 > (http://xenbits.xen.org/xen-4.0-testing.hg/objects/00/00000000000000000000000000000000000000) > corrupt > Getting pack list for http://xenbits.xen.org/xen-4.0-testing.hg > Getting alternates list for http://xenbits.xen.org/xen-4.0-testing.hg > Also look at <a href="http://www.selenic.com/mercurial/">mercur > Getting pack list for <a href="http://www.selenic.com/mercurial/">mercur > error: Protocol <a href="http not supported or disabled in libcurl > error: Unable to find 0000000000000000000000000000000000000000 under > http://xenbits.xen.org/xen-4.0-testing.hg > Cannot obtain needed object 0000000000000000000000000000000000000000 > fatal: Fetch failed. > > > > Does anyone have a fresh copy of xen repo? I''d like to try "git bisect". > > -- > > S pozdravem > Josef Liška > > CHL | system care > > Telefon: +420.272048055 > Fax: +420.272048064 > Mobil: +420.776026526 denně 9:00 - 17:30 > Jabber: jl@chl.cz > https://www.chl.cz/ > > !DSPAM:2,4cd954a0114761276564610! > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > !DSPAM:2,4cd954a0114761276564610! >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
yum update libvirt will install 0.8.3.
Does it help ?
Boris.
--- On Tue, 11/9/10, Josef Liška <jl@chl.cz> wrote:
From: Josef Liška <jl@chl.cz>
Subject: [Xen-users] git error
To: xen-users@lists.xensource.com
Date: Tuesday, November 9, 2010, 9:00 AM
Hi list,
I am hunting a bug between libvirt and xen, which seems to appeared
after xen-4.0.1rc3.
The problem is a "pipe leak". Each connection to libvirt leaves 3 open
files:
libvirtd 14758 root 18u unix
0xffff88002600ed00 351779 socket
libvirtd 14758 root 19r FIFO
0,8 351781 pipe
libvirtd 14758 root 20w FIFO
0,8 351781 pipe
Steps to reproduce:
1. install xen-4.0.1 and libvirt 0.7.6+
2. for i in `seq 1 1000`; do virsh -c xen://daman.vmin.cz list; done
if fails on "Too many open files"
After libvirt restart, works fine for cca 300 connections
I have not seen this with xen-3. Since libvirt links libxenstore:
libxenstore.so.3.0 => /usr/lib/libxenstore.so.3.0
(0x00007f8845fea000)
and since I have a box with xen-4.0.1rc3 which seems to work well, I
have tried to replace libxenstore.so.3.0 with one from older box.
Voila, no "pipe leak".
Now I would like to look into sources and try to find which change
introduced this behavior. Unfortunatelly,
I am unable to clone git repo:
los:/mnt/y# git clone http://xenbits.xen.org/xen-4.0-testing.hg
Initialized empty Git repository in /mnt/y/xen-4.0-testing.hg/.git/
error: File 0000000000000000000000000000000000000000
(http://xenbits.xen.org/xen-4.0-testing.hg/objects/00/00000000000000000000000000000000000000)
corrupt
Getting pack list for http://xenbits.xen.org/xen-4.0-testing.hg
Getting alternates list for http://xenbits.xen.org/xen-4.0-testing.hg
Also look at <a href="http://www.selenic.com/mercurial/">mercur
Getting pack list for <a
href="http://www.selenic.com/mercurial/">mercur
error: Protocol <a href="http not supported or disabled in libcurl
error: Unable to find 0000000000000000000000000000000000000000 under
http://xenbits.xen.org/xen-4.0-testing.hg
Cannot obtain needed object 0000000000000000000000000000000000000000
fatal: Fetch failed.
Does anyone have a fresh copy of xen repo? I''d like to try "git
bisect".
--
S pozdravem
Josef Liška
CHL | system care
Telefon: +420.272048055
Fax: +420.272048064
Mobil: +420.776026526 denně 9:00 - 17:30
Jabber: jl@chl.cz
https://www.chl.cz/
-----Inline Attachment Follows-----
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Hi, I am on debian, so no yum here. Last libvirt version tested here is: ii libvirt-bin 0.8.4-1 the programs for the libvirt library It seems to be in libxenstore. Does libvirt from your yum repo have any specific patches? (yum source libvirt and inspect /usr/src/redhat/SOURCES). S pozdravem Josef Liška CHL | system care Telefon: +420.272048055 Fax: +420.272048064 Mobil: +420.776026526 denně 9:00 - 17:30 Jabber: jl@chl.cz https://www.chl.cz/ Dne 9.11.2010 15:26, Boris Derzhavets napsal(a):> yum update libvirt will install 0.8.3. > Does it help ? > > Boris. > > --- On *Tue, 11/9/10, Josef Liška /<jl@chl.cz>/* wrote: > > > From: Josef Liška <jl@chl.cz> > Subject: [Xen-users] git error > To: xen-users@lists.xensource.com > Date: Tuesday, November 9, 2010, 9:00 AM > > Hi list, > I am hunting a bug between libvirt and xen, which seems to > appeared after xen-4.0.1rc3.. > > The problem is a "pipe leak". Each connection to libvirt leaves 3 > open files: > libvirtd 14758 root 18u unix > 0xffff88002600ed00 351779 socket > libvirtd 14758 root 19r FIFO > 0,8 351781 pipe > libvirtd 14758 root 20w FIFO > 0,8 351781 pipe > > Steps to reproduce: > 1. install xen-4.0.1 and libvirt 0.7.6+ > 2. for i in `seq 1 1000`; do virsh -c xen://daman.vmin.cz list; done > if fails on "Too many open files" > > After libvirt restart, works fine for cca 300 connections > > > I have not seen this with xen-3. Since libvirt links libxenstore: > libxenstore.so.3.0 => /usr/lib/libxenstore.so.3.0 > (0x00007f8845fea000) > and since I have a box with xen-4.0.1rc3 which seems to work well, > I have tried to replace libxenstore.so.3.0 with one from older > box. Voila, no "pipe leak". > > Now I would like to look into sources and try to find which change > introduced this behavior. Unfortunatelly, > I am unable to clone git repo: > > > los:/mnt/y# git clone http://xenbits.xen.org/xen-4.0-testing.hg > Initialized empty Git repository in /mnt/y/xen-4.0-testing.hg/.git/ > error: File 0000000000000000000000000000000000000000 > (http://xenbits.xen.org/xen-4.0-testing.hg/objects/00/00000000000000000000000000000000000000) > corrupt > Getting pack list for http://xenbits.xen.org/xen-4.0-testing.hg > Getting alternates list for http://xenbits.xen.org/xen-4.0-testing.hg > Also look at <a href="http://www.selenic.com/mercurial/" > <http://www.selenic.com/mercurial/>>mercur > Getting pack list for <a href="http://www.selenic.com/mercurial/" > <http://www.selenic.com/mercurial/>>mercur > error: Protocol <a href="http not supported or disabled in libcurl > error: Unable to find 0000000000000000000000000000000000000000 > under http://xenbits.xen.org/xen-4.0-testing.hg > Cannot obtain needed object 0000000000000000000000000000000000000000 > fatal: Fetch failed. > > > > Does anyone have a fresh copy of xen repo? I''d like to try "git > bisect". > > -- > > S pozdravem > Josef Liška > > CHL | system care > > Telefon: +420.272048055 > Fax: +420.272048064 > Mobil: +420.776026526 denně 9:00 - 17:30 > Jabber: jl@chl.cz </mc/compose?to=jl@chl.cz> > https://www.chl.cz/ > > > -----Inline Attachment Follows----- > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > </mc/compose?to=Xen-users@lists.xensource.com> > http://lists.xensource.com/xen-users > > > !DSPAM:2,4cd95a15114761503711497!_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
> It seems to be in libxenstore. Does libvirt from your yum repo have anyspecific patches?> (yum source libvirt and inspect/usr/src/redhat/SOURCES). To honest i don''t know. I don''t have so many connections, so . . . . But , on Ubuntu 10.10 current version of libvirt is 0.8.3 . It works with Xen (8-10 connections tested ) Boris. --- On Tue, 11/9/10, Josef Liška <jl@chl.cz> wrote: From: Josef Liška <jl@chl.cz> Subject: Re: [Xen-users] git error To: xen-users@lists.xensource.com Cc: "Boris Derzhavets" <bderzhavets@yahoo.com> Date: Tuesday, November 9, 2010, 9:58 AM Hi, I am on debian, so no yum here. Last libvirt version tested here is: ii libvirt-bin 0.8.4-1 the programs for the libvirt library It seems to be in libxenstore. Does libvirt from your yum repo have any specific patches? (yum source libvirt and inspect /usr/src/redhat/SOURCES). S pozdravem Josef Liška CHL | system care Telefon: +420.272048055 Fax: +420.272048064 Mobil: +420.776026526 denně 9:00 - 17:30 Jabber: jl@chl.cz https://www.chl.cz/ Dne 9.11.2010 15:26, Boris Derzhavets napsal(a): yum update libvirt will install 0.8.3. Does it help ? Boris. --- On Tue, 11/9/10, Josef Liška <jl@chl.cz> wrote: From: Josef Liška <jl@chl.cz> Subject: [Xen-users] git error To: xen-users@lists.xensource.com Date: Tuesday, November 9, 2010, 9:00 AM Hi list, I am hunting a bug between libvirt and xen, which seems to appeared after xen-4.0.1rc3.. The problem is a "pipe leak". Each connection to libvirt leaves 3 open files: libvirtd 14758 root 18u unix 0xffff88002600ed00 351779 socket libvirtd 14758 root 19r FIFO 0,8 351781 pipe libvirtd 14758 root 20w FIFO 0,8 351781 pipe Steps to reproduce: 1. install xen-4.0.1 and libvirt 0.7.6+ 2. for i in `seq 1 1000`; do virsh -c xen://daman.vmin.cz list; done if fails on "Too many open files" After libvirt restart, works fine for cca 300 connections I have not seen this with xen-3. Since libvirt links libxenstore: libxenstore.so.3.0 => /usr/lib/libxenstore.so.3.0 (0x00007f8845fea000) and since I have a box with xen-4.0.1rc3 which seems to work well, I have tried to replace libxenstore.so.3.0 with one from older box. Voila, no "pipe leak". Now I would like to look into sources and try to find which change introduced this behavior. Unfortunatelly, I am unable to clone git repo: los:/mnt/y# git clone http://xenbits.xen.org/xen-4.0-testing.hg Initialized empty Git repository in /mnt/y/xen-4.0-testing.hg/.git/ error: File 0000000000000000000000000000000000000000 (http://xenbits.xen.org/xen-4.0-testing.hg/objects/00/00000000000000000000000000000000000000) corrupt Getting pack list for http://xenbits.xen.org/xen-4.0-testing.hg Getting alternates list for http://xenbits.xen.org/xen-4.0-testing.hg Also look at <a href="http://www.selenic.com/mercurial/">mercur Getting pack list for <a href="http://www.selenic.com/mercurial/">mercur error: Protocol <a href="http not supported or disabled in libcurl error: Unable to find 0000000000000000000000000000000000000000 under http://xenbits.xen.org/xen-4.0-testing.hg Cannot obtain needed object 0000000000000000000000000000000000000000 fatal: Fetch failed. Does anyone have a fresh copy of xen repo? I''d like to try "git bisect". -- S pozdravem Josef Liška CHL | system care Telefon: +420.272048055 Fax: +420.272048064 Mobil: +420.776026526 denně 9:00 - 17:30 Jabber: jl@chl.cz https://www.chl.cz/ -----Inline Attachment Follows----- _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users !DSPAM:2,4cd95a15114761503711497! _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, list
I have done regression testing using git bisect and found following commit:
8b490610757b1c81131c1876a54fd0bfec301c52 is first bad commit
commit 8b490610757b1c81131c1876a54fd0bfec301c52
Author: Keir Fraser <keir.fraser@citrix.com>
Date: Tue Jul 6 16:49:01 2010 +0100
libxl: Backported stuff from unstable
Signed-off-by: Gianni Tedesco <gianni.tedesco@citrix.com>
:040000 040000 54ca1943b0e67e41b0114a5c530a4cbe8064d1e6
14368197c6bcac10010bf0b34e9aba5edb2cce9f
It is a big patch (cca 300k), but only changes 2 files in xenstore: xs.c
and xs.h. Separated patch for only xenstore folder
has 2k.
Next step is to try reverting changes in those files, but keep new libxl.
diff -Naur a/xenstore/xs.c b/xenstore/xs.c
--- a/xenstore/xs.c 2010-11-10 00:59:57.000000000 +0100
+++ b/xenstore/xs.c 2010-11-10 01:02:42.000000000 +0100
@@ -236,21 +236,9 @@
return get_handle(xs_domain_dev());
}
-void xs_daemon_close(struct xs_handle *h)
-{
+static void close_free_msgs(struct xs_handle *h) {
struct xs_stored_msg *msg, *tmsg;
-#ifdef USE_PTHREAD
- if (h->read_thr_exists) {
- pthread_cancel(h->read_thr);
- pthread_join(h->read_thr, NULL);
- }
-#endif
-
- mutex_lock(&h->request_mutex);
- mutex_lock(&h->reply_mutex);
- mutex_lock(&h->watch_mutex);
-
list_for_each_entry_safe(msg, tmsg, &h->reply_list, list) {
free(msg->body);
free(msg);
@@ -260,11 +248,9 @@
free(msg->body);
free(msg);
}
+}
- mutex_unlock(&h->request_mutex);
- mutex_unlock(&h->reply_mutex);
- mutex_unlock(&h->watch_mutex);
-
+static void close_fds_free(struct xs_handle *h) {
if (h->watch_pipe[0] != -1) {
close(h->watch_pipe[0]);
close(h->watch_pipe[1]);
@@ -275,6 +261,32 @@
free(h);
}
+void xs_daemon_destroy_postfork(struct xs_handle *h)
+{
+ close_free_msgs(h);
+ close_fds_free(h);
+}
+
+void xs_daemon_close(struct xs_handle *h)
+{
+#ifdef USE_PTHREAD
+ if (h->read_thr_exists) {
+ pthread_cancel(h->read_thr);
+ pthread_join(h->read_thr, NULL);
+ }
+#endif
+
+ mutex_lock(&h->request_mutex);
+ mutex_lock(&h->reply_mutex);
+ mutex_lock(&h->watch_mutex);
+
+ close_free_msgs(h);
+
+ mutex_unlock(&h->request_mutex);
+ mutex_unlock(&h->reply_mutex);
+ mutex_unlock(&h->watch_mutex);
+}
+
static bool read_all(int fd, void *data, unsigned int len)
{
while (len) {
diff -Naur a/xenstore/xs.h b/xenstore/xs.h
--- a/xenstore/xs.h 2010-11-10 00:59:57.000000000 +0100
+++ b/xenstore/xs.h 2010-11-10 01:02:42.000000000 +0100
@@ -48,6 +48,9 @@
/* Close the connection to the xs daemon. */
void xs_daemon_close(struct xs_handle *);
+/* Throw away the connection to the xs daemon, for use after fork(). */
+void xs_daemon_destroy_postfork(struct xs_handle *);
+
/* Get contents of a directory.
* Returns a malloced array: call free() on it after use.
* Num indicates size.
Best regards
Josef Liška
CHL | system care
Telefon: +420.272048055
Fax: +420.272048064
Mobil: +420.776026526 denně 9:00 - 17:30
Jabber: jl@chl.cz
https://www.chl.cz/
Dne 9.11.2010 16:53, Boris Derzhavets napsal(a):> > It seems to be in libxenstore. Does libvirt from your yum repo have
> any specific patches?
> > (yum source libvirt and inspect /usr/src/redhat/SOURCES).
> To honest i don''t know. I don''t have so many connections,
so . . . .
> But , on Ubuntu 10.10 current version of libvirt is 0.8.3 . It works
> with Xen (8-10 connections tested )
>
> Boris.
>
> --- On *Tue, 11/9/10, Josef Liška /<jl@chl.cz>/* wrote:
>
>
> From: Josef Liška <jl@chl.cz>
> Subject: Re: [Xen-users] git error
> To: xen-users@lists.xensource.com
> Cc: "Boris Derzhavets" <bderzhavets@yahoo.com>
> Date: Tuesday, November 9, 2010, 9:58 AM
>
> Hi,
> I am on debian, so no yum here. Last libvirt version tested here is:
> ii libvirt-bin 0.8.4-1 the programs for the
> libvirt library
>
> It seems to be in libxenstore. Does libvirt from your yum repo
> have any specific patches? (yum source libvirt and inspect
> /usr/src/redhat/SOURCES).
>
> S pozdravem
> Josef Liška
>
> CHL | system care
>
> Telefon: +420.272048055
> Fax: +420.272048064
> Mobil: +420.776026526 denně 9:00 - 17:30
> Jabber: jl@chl.cz </mc/compose?to=jl@chl.cz>
> https://www.chl.cz/
>
>
> Dne 9.11.2010 15:26, Boris Derzhavets napsal(a):
>> yum update libvirt will install 0.8.3.
>> Does it help ?
>>
>> Boris.
>>
>> --- On *Tue, 11/9/10, Josef Liška /<jl@chl.cz>
>> </mc/compose?to=jl@chl.cz>/* wrote:
>>
>>
>> From: Josef Liška <jl@chl.cz>
</mc/compose?to=jl@chl.cz>
>> Subject: [Xen-users] git error
>> To: xen-users@lists.xensource.com
>> </mc/compose?to=xen-users@lists.xensource.com>
>> Date: Tuesday, November 9, 2010, 9:00 AM
>>
>> Hi list,
>> I am hunting a bug between libvirt and xen, which seems to
>> appeared after xen-4.0.1rc3..
>>
>> The problem is a "pipe leak". Each connection to
libvirt
>> leaves 3 open files:
>> libvirtd 14758 root 18u unix
>> 0xffff88002600ed00 351779 socket
>> libvirtd 14758 root 19r FIFO
>> 0,8 351781 pipe
>> libvirtd 14758 root 20w FIFO
>> 0,8 351781 pipe
>>
>> Steps to reproduce:
>> 1. install xen-4.0.1 and libvirt 0.7.6+
>> 2. for i in `seq 1 1000`; do virsh -c xen://daman.vmin.cz
>> list; done
>> if fails on "Too many open files"
>>
>> After libvirt restart, works fine for cca 300 connections
>>
>>
>> I have not seen this with xen-3. Since libvirt links
libxenstore:
>> libxenstore.so.3.0 => /usr/lib/libxenstore.so.3.0
>> (0x00007f8845fea000)
>> and since I have a box with xen-4.0.1rc3 which seems to work
>> well, I have tried to replace libxenstore.so.3.0 with one
>> from older box. Voila, no "pipe leak".
>>
>> Now I would like to look into sources and try to find which
>> change introduced this behavior. Unfortunatelly,
>> I am unable to clone git repo:
>>
>>
>> los:/mnt/y# git clone http://xenbits.xen.org/xen-4.0-testing.hg
>> Initialized empty Git repository in
>> /mnt/y/xen-4.0-testing.hg/.git/
>> error: File 0000000000000000000000000000000000000000
>>
(http://xenbits.xen.org/xen-4.0-testing.hg/objects/00/00000000000000000000000000000000000000)
>> corrupt
>> Getting pack list for http://xenbits.xen.org/xen-4.0-testing.hg
>> Getting alternates list for
>> http://xenbits.xen.org/xen-4.0-testing.hg
>> Also look at <a
href="http://www.selenic.com/mercurial/"
>> <http://www.selenic.com/mercurial/>>mercur
>> Getting pack list for <a
>> href="http://www.selenic.com/mercurial/"
>> <http://www.selenic.com/mercurial/>>mercur
>> error: Protocol <a href="http not supported or disabled
in
>> libcurl
>> error: Unable to find
>> 0000000000000000000000000000000000000000 under
>> http://xenbits.xen.org/xen-4.0-testing.hg
>> Cannot obtain needed object
>> 0000000000000000000000000000000000000000
>> fatal: Fetch failed.
>>
>>
>>
>> Does anyone have a fresh copy of xen repo? I''d like to
try
>> "git bisect".
>>
>> --
>>
>> S pozdravem
>> Josef Liška
>>
>> CHL | system care
>>
>> Telefon: +420.272048055
>> Fax: +420.272048064
>> Mobil: +420.776026526 denně 9:00 - 17:30
>> Jabber: jl@chl.cz
>> https://www.chl.cz/
>>
>>
>> -----Inline Attachment Follows-----
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xensource.com
>> http://lists.xensource.com/xen-users
>>
>>
>
> !DSPAM:2,4cd96e94114762127911200!
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users
Hello, Am Mittwoch 10 November 2010 08:10:19 schrieb Josef Liška:> I have done regression testing using git bisect and found following commit:...> commit 8b490610757b1c81131c1876a54fd0bfec301c52...> diff -Naur a/xenstore/xs.h b/xenstore/xs.h > --- a/xenstore/xs.h 2010-11-10 00:59:57.000000000 +0100 > +++ b/xenstore/xs.h 2010-11-10 01:02:42.000000000 +0100 > @@ -48,6 +48,9 @@ > /* Close the connection to the xs daemon. */ > void xs_daemon_close(struct xs_handle *); > > +/* Throw away the connection to the xs daemon, for use after fork(). */ > +void xs_daemon_destroy_postfork(struct xs_handle *);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 -- Philipp Hahn Open Source Software Engineer hahn@univention.de Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 28359 Bremen fax: +49 421 22 232-99 http://www.univention.de _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Hi, that was usefull comment, thank you! I''ll share results later. Best regards Josef Liška CHL | system care Telefon: +420.272048055 Fax: +420.272048064 Mobil: +420.776026526 denně 9:00 - 17:30 Jabber: jl@chl.cz https://www.chl.cz/ Dne 10.11.2010 08:48, Philipp Hahn napsal(a):> Hello, > > Am Mittwoch 10 November 2010 08:10:19 schrieb Josef Liška: > >> I have done regression testing using git bisect and found following commit: >> > ... > >> commit 8b490610757b1c81131c1876a54fd0bfec301c52 >> > ... > >> diff -Naur a/xenstore/xs.h b/xenstore/xs.h >> --- a/xenstore/xs.h 2010-11-10 00:59:57.000000000 +0100 >> +++ b/xenstore/xs.h 2010-11-10 01:02:42.000000000 +0100 >> @@ -48,6 +48,9 @@ >> /* Close the connection to the xs daemon. */ >> void xs_daemon_close(struct xs_handle *); >> >> +/* Throw away the connection to the xs daemon, for use after fork(). */ >> +void xs_daemon_destroy_postfork(struct xs_handle *); >> > 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 > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users > > !DSPAM:2,4cda4ebd114768778217422! >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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@chl.cz 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 > > > >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
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@chl.cz 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@chl.cz > 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@lists.xensource.com > http://lists.xensource.com/xen-users > > !DSPAM:2,4cdaa395114764967921375! >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users