[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-API] [PATCH] Cope with the stunnel zombie process issue


  • To: xen-api@xxxxxxxxxxxxxxxxxxx
  • From: Zheng Li <dev@xxxxxxxx>
  • Date: Tue, 20 Apr 2010 18:25:01 -0000
  • Delivery-date: Tue, 20 Apr 2010 11:26:05 -0700
  • List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>

Some versions of stunnel (old versions, or some new ones bulit with some 
particular Linux distribution versions) have the zombie process issue when 
called from xe. When it happens, the main stunnel process won't exit for long 
time after xe closing its communication channel, seems to be waiting for its 
children processes which are however staying in "defunct" status. The issue was 
also reported on the server side when stunnel is called by xapi daemon, so it 
would be useful to set the Stunnel.disconnect arguments properly there as well. 
However this demands more work to identify which setting is safe for each 
occurrence, so I'll leave it for future. Moreover, currently xe doesn't wait 
for the second stunnel connection process (HTTP Get/Put), this should also be 
fixed in the future. The question is: does xe really needs to care about the 
status of stunnel in most cases? If not, why not using the double fork tricks 
everywhere; if yes, a SSL library might be more appropriate than 
 3rd party tools such as stunnel.

Signed-off-by: Zheng Li <dev@xxxxxxxx>


 ocaml/xe-cli/newcli.ml |  24 +++++++++++-------------
 1 files changed, 11 insertions(+), 13 deletions(-)


diff -r aadacd259d22 -r 09806785f1ae ocaml/xe-cli/newcli.ml
--- a/ocaml/xe-cli/newcli.ml    Sat Apr 10 12:42:44 2010 +0100
+++ b/ocaml/xe-cli/newcli.ml    Tue Apr 20 19:18:53 2010 +0100
@@ -115,11 +115,10 @@
     with End_of_file ->
       error "Error: password file format: expecting username on the first 
line, password on the second line\n";
       exit 1
-  with
-    | _ ->
-       error "Error opening password file '%s'\n" !xapipasswordfile;
-       exit 1
-         
+  with _ ->
+    error "Error opening password file '%s'\n" !xapipasswordfile;
+    exit 1
+
 
 let parse_port (x: string) = 
   try
@@ -337,9 +336,9 @@
                        doit url
                with
                | ClientSideError msg ->
-                         marshal ofd (Response Failed);
-                         Printf.fprintf stderr "Operation failed. Error: %s\n" 
msg;
-                         exit 1                    
+              marshal ofd (Response Failed);
+              Printf.fprintf stderr "Operation failed. Error: %s\n" msg;
+              exit_code := Some 1
                | e ->
                          debug "HttpPut failure: %s\n%!" (Printexc.to_string 
e);
                          (* Assume the server will figure out what's wrong and 
tell us over
@@ -401,9 +400,9 @@
                  doit url
                with 
                | ClientSideError msg ->
-                         marshal ofd (Response Failed);
-                         Printf.fprintf stderr "Operation failed. Error: %s\n" 
msg;
-                         exit 1                    
+              marshal ofd (Response Failed);
+              Printf.fprintf stderr "Operation failed. Error: %s\n" msg;
+              exit_code := Some 1
                | e ->
                          debug "HttpGet failure: %s\n%!" (Printexc.to_string 
e);
                          marshal ofd (Response Failed) 
@@ -508,8 +507,7 @@
              with e -> debug "%s\n" (Printexc.to_string e));
           try Unix.unlink p.Stunnel.logfile with _ -> ()
         end;
-      (try Stunnel.disconnect p 
-       with Unix.Unix_error(Unix.ECHILD, _, _) -> ())
+      Stunnel.disconnect ~wait:false ~force:true p
   | None -> ()
   end;
   begin match !debug_file, !debug_channel with

Attachment: xen-api.patch
Description: Text Data

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.