Print

Print


This behaviour is not new. It's been this was for at least a decade if not 
more. The issue is that it depends on the host name being properly 
registed to work in an expected way, though you can force the resolution 
if this is not he case. In Bockjoo's case, security rules apparently 
require some strange hoops in how the host is internally registered and 
this is what is causing this behaviour. I know of only two sites that are 
experiencing this and each has come up with a solution, though I can't say 
it's straightforward.

Andy

On Wed, 14 Sep 2022, Mátyás Selmeci wrote:

> Hi Andy,
>
> So is this behavior new? Should OSG highlight it in our release notes?
>
> -Mat
>
> On 9/12/2022 5:00 PM, Bockjoo Kim wrote:
>> Hi Andy,
>> 
>> Your explanation makes sense. I was suspecting it, too.
>> 
>> Thanks,
>> 
>> Bockjoo
>> 
>> On 9/12/22 17:28, Andrew Hanushevsky wrote:
>>> Hi Bockjoo,
>>> 
>>> Ah, I think I misunderstood you delimma. This must have been for the 
>>> actual manager cmsd. So, the xrd.port directive simply says which port to 
>>> open for incomming connections, Since 1094 is likely used by the 
>>> corresponding xrootd the cmsd cannot open it as well. So, that is why you 
>>> need to gaurd it with the "if exec xrootd".
>>> 
>>> Now, a manager cmsd determine the port it should be using from the 
>>> "all.manager" directive. If the host name in that directive matches the 
>>> host name assigned to it then it takes the port from that directive. If 
>>> none match then it must be taken from the xrd.port directive.
>>> 
>>> Now I do know from out past conversations that host name assignment at 
>>> your site is rather complicated and that host name matching might not 
>>> occur. That would explain why you also need to specify the xrd.port 
>>> directive.
>>> 
>>> I hope this explains it.
>>> 
>>> Andy
>>> 
>>> On Mon, 12 Sep 2022, Bockjoo Kim wrote:
>>> 
>>>> Hi Andy,
>>>> 
>>>> That's strange.
>>>> 
>>>> I have to explicitly add :
>>>> 
>>>> xrd.port 1094 if exec xrootd
>>>> 
>>>> xrd.port 1213 if exec cmsd
>>>> 
>>>> Otherwise, cmsd fails to start with the error the port 1094 already in 
>>>> use.
>>>> 
>>>> Thanks,
>>>> 
>>>> Bockjoo
>>>> 
>>>> On 9/12/22 14:28, Andrew Hanushevsky wrote:
>>>>> Hi Bockjoo,
>>>>> 
>>>>> No, none of that code changed in 5.4.3. The all.manager directive 
>>>>> specifically directs the cmsd to use 1213, and is required. The xrd.port 
>>>>> directive simply says what the inboucd port should be.
>>>>> 
>>>>> Andy
>>>>> 
>>>>> 
>>>>> On Mon, 12 Sep 2022, Bockjoo Kim wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I have upgraded my redirector to 5.4.3 recently.
>>>>>> 
>>>>>> Perhaps I forgot to restart cmsd after that.
>>>>>> 
>>>>>> For some reason, the redirector died today and I tried to restart cmsd 
>>>>>> and it was trying to open 1094 port instead of 1213 port.
>>>>>> 
>>>>>> My config looked like:
>>>>>> 
>>>>>> xrd.port 1094
>>>>>> all.role manager
>>>>>> all.manager cmsio7.rc.ufl.edu:1213
>>>>>> ....
>>>>>> 
>>>>>> In the previous xrootd versions, the cmsd process correctly picked up 
>>>>>> 1213 port.
>>>>>> 
>>>>>> Is this behavior changed with the xrootd 5.4.3?
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Bockjoo
>>>>>> 
>>>>>> ########################################################################
>>>>>> Use REPLY-ALL to reply to list
>>>>>> 
>>>>>> To unsubscribe from the XROOTD-L list, click the following link:
>>>>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1
>>>>>> 
>>>> 
>> 
>> ########################################################################
>> Use REPLY-ALL to reply to list
>> 
>> To unsubscribe from the XROOTD-L list, click the following link:
>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1
>

########################################################################
Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1