 |
 |
The trigger issue here is the way the proxy server handles its start-up. It doesn't fork before calling the client to setup the connection. That's what blocked eveything. It's fixable. I'm just hoping that we don't keep bumping into things like this because of the serial nature of init.d. So, I'll fix this one. Andy On Fri, 13 May 2011, Brian Bockelman wrote: > Grr - apparently, the airport IP address is blocked by Savannah, so I must email. > > My understanding from the comments in commit b6c2cf0f1e221cd925999fd95eee93073c728474 is that the daemons should fork, the child parses the config, and then informs the parent when it is successful. The parent then exits and the init script gets the status. > > However, if you're seeing blocking due to ordering in init... well, my understanding is obviously incorrect. Is this something which is fixable? > > Brian > > On May 13, 2011, at 9:25 AM, anonymous wrote: > >> Follow-up Comment #2, bug #82184 (project xrootd): >> >> Actually Brian it has everything to do with how /etc/init.d/ is >> run. The design of xrootd is independent of the sequential nature of the >> /etc/init.d/ scripts look at daemon command inside >> the /etc/rc.d/init.d/functions >> >> >> _______________________________________________________ >> >> Reply to this item at: >> >> <http://savannah.cern.ch/bugs/?82184> >> >> _______________________________________________ >> Message sent via/by LCG Savannah >> http://savannah.cern.ch/ > >