Yes, that was a typo. Looking back at the logs, the hostnames match.

As for fencing. We still do fencing for the all.pidpath directive but not for the '-s' command line option. This is in keeping of what systemd expects.

by the way, talking about what systemd and an administrator would expect, i would say that all directives that do fencing
(-a, -w) should have the = option of log option. to give full control and expectations to the administrator

Point (2) No you don't have to do anything. This was a config re-parse error. It shouldn't have happened but, in practice, didn't affect anything other than put out a misleading message.

ok, got it

Point (3) Idle links produce almost no contention. The only reason you want to trim idle links is to make more file descriptors available. Generally, you likely have more than enough. Most sites, if they use this directive, specify an idle timeout on the order of 10 to 20 minutes. A timeout of 20 seconds may actually decrease the performance of root jobs as many of them read some data and then take a minute or so to process what they read. In the mean time the links gets closed and has to get re-established. Of course, that depends on the kind of jobs you are running.

As what directives apply, the "xrd." prefixed directive applies to anything that uses the "xrd" protocol driver framework. So, in this case, xrootd and cmsd. Note that each of those has a different directive prefix. In other scenarios it would apply to DPM, EOS, and other similar systems that use the "xrd" framework. I strongly suggest you increase that to about 20 minutes.

ok, increased to 300s :)

I will look at the new logs. One thing that is for sure is there is a mismatch between what the xrootd thinks the environment is and what the cmsd thinks.

i added in the cernbox directory also the /proc content and the .env files of the services

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Use REPLY-ALL to reply to list

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