Print

Print


Yes, I agree with all of us as well. Things should get easier with the new 
init.d tool in the next RH release. In the mean time, plug-in creators have 
to be aware of how to write non-blocking configurations. Though I can 
imagine that at times that will be very difficult to do and perhaps 
impossible. So, it's likely we will have to revisit this. Anyway, I 
committed the change to the proxy to not stall the configuration of the 
origin server is not available. I don't know of anything else in the vanilla 
code that would cause init.d to stall.

Andy

-----Original Message----- 
From: Doug Benjamin
Sent: Tuesday, May 17, 2011 5:14 AM
To: Lukasz Janyst
Cc: Andrew Hanushevsky ; Brian Bockelman ; [log in to unmask] ; 
Lukasz Janyst
Subject: Re: [bug #82184] Problem for startup using /etc/init.d and proxy 
services

Hi,

   I agree with both of you.  Personally I would like "set and forget"
for xrootd using standard tools. (I am sure with SL7 the tools will
change again).
It will be the easiest to help support and get others to use.
I also understand that is might force design changes and refactoring
of the code.

  I think that it is important that the services be able to startup in any
order and we do not see the blocking actions that Andy and I enjoyed
so much last Thursday.

Cheers,

Doug

On May 17, 2011, at 2:39 AM, Lukasz Janyst wrote:

> Hi Andy,
>
>   you have a good point here, but I think that we should really try
> to integrate nicely with the operating systems we're running on
> because this seriously eases up the administration and makes people
> more eager to adopt XRootD. If people type "yum install xrootd-server"
> and everything just works out of the box the way they expect it to
> then it really makes people feel that all this is good. Whereas if
> they have to untar the binaries and worry how to make the services
> start (or reastart correctly on the system reboot) and know exactly in
> what order this should be done, when they need to write cron jobs and
> dig through manuals to handle their logs and so on, then before they
> even run anything and realize that it's very good, their reaction will
> not be favorable to say the least.
>
> Cheers,
>   Lukasz
>
> 2011/5/16 Andrew Hanushevsky <[log in to unmask]>:
>> Adding two cents here...  while I can "fix" the proxy start-up (in a 
>> rather
>> internally ugly way) this is just the tip of the iceberg. I can foresee
>> cases (and they probably exist already) where a seemingly benign plugin
>> requires some information from a server in Novosibirsk to complete
>> initialization and the whole system hangs simply because that server is 
>> not
>> available. Things seem to be written this way because rarely one thinks 
>> that
>> start-up will be a serial process. And, in fact, it shouldn't be. So, to 
>> me
>> it's a clear case of forcing a square peg into a round hole; just 
>> because.
>>
>> Andy
>>
>> -----Original Message----- From: Lukasz Janyst
>> Sent: Monday, May 16, 2011 12:48 AM
>> To: Andrew Hanushevsky ; Brian Bockelman ; Lukasz Janyst ; Doug Benjamin 
>> ;
>> [log in to unmask]
>> Subject: [bug #82184] Problem for startup using /etc/init.d and proxy
>> services
>>
>>
>> Follow-up Comment #3, bug #82184 (project xrootd):
>>
>> The System-V init procedure in Unix is and always has been serial. I 
>> don't
>> think it's a big deal though and Brian is right by saying that it can 
>> easily
>> be handled by managing more carefully which procedures are handled before
>> and
>> which are handled after the child process detaches from the parent (this
>> should be minor change that requires no modification to the general 
>> design
>> of
>> xrootd).
>>
>> When everyone migrates to upstart (http://upstart.ubuntu.com/) one could
>> start thinking of migrating to an event based startup, but until then the
>> serial one needs to be supported.
>>
>>   _______________________________________________________
>>
>> Reply to this item at:
>>
>>  <http://savannah.cern.ch/bugs/?82184>
>>
>> _______________________________________________
>>  Message sent via/by LCG Savannah
>>  http://savannah.cern.ch/
>>