overwrite config parameter does not work

[juztas]

Here is setup:
xrootd-clustered.cfg - default file and there is continue /etc/xrootd/config.d/
inside /etc/xrootd/config.d/ we have:

# ll
total 16
-rw-r--r-- 1 root root  413 Jun 30  2020 10-xrootd-lcmaps.cfg
-rw-r--r-- 1 root root 1156 Jun 30  2020 40-xrootd-lcmaps.cfg
-rw-r--r-- 1 root root  483 Sep 22 15:12 60-osg-multiuser.cfg
-rw-r--r-- 1 root root 3469 Sep 22 13:38 99-local.cfg

60-osg-multiuser.cfg defines:

xrootd.chksum max 2 md5 adler32 crc32

99-local.cfg defines:

xrootd.chksum max 10 adler32

I would expect that 99-local.cfg takes priority as being the last one and any param defined in 99-local overwrites found before. But seems this is not the case:

# getfattr -d -m - /storage/cms/store/user/jbalcas/4.root
getfattr: Removing leading '/' from absolute path names
# file: storage/cms/store/user/jbalcas/4.root
user.XrdCks.Human.ADLER32="3743254b"
user.XrdCks.Human.CRC32="e2b17be0"
user.XrdCks.Human.MD5="196013e343001da42c2b7390a68fe191"
user.XrdCks.adler32=0sYWRsZXIzMgAAAAAAAAAAAAAAAABhS6qzAAAAAAAAAAQ3QyVLAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
user.XrdCks.crc32=0sY3JjMzIAAAAAAAAAAAAAAAAAAABhS6qzAAAAAAAAAATisXvgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
user.XrdCks.md5=0sbWQ1AAAAAAAAAAAAAAAAAAAAAABhS6qzAAAAAAAAABAZYBPjQwAdpCwrc5Cmj+GRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

While it should have only adler32 defined. I tried to move 99-local.cfg to 01.local.cfg - but this made 0 diff. It still calculates all checksums. Once I comment out xrootd.chksum on 60-osg-multiuser.cfg - then it works and calculates only adler32.

What could be wrong here?

Xrootd server start indicates that 99-local config was read the last:

210922 15:13:00 2847809 sysTPCInitialize: Will load configuration for the TPC handler from /etc/xrootd/xrootd-clustered.cfg
=====> continue /etc/xrootd/config.d/
Config continuing with file /etc/xrootd/config.d/10-xrootd-lcmaps.cfg ...
Config continuing with file /etc/xrootd/config.d/40-xrootd-lcmaps.cfg ...
Config continuing with file /etc/xrootd/config.d/60-osg-multiuser.cfg ...
Config continuing with file /etc/xrootd/config.d/99-local.cfg ...
=====> http.desthttps yes
210922 15:13:00 2847809 TPC_TempCA: Reloading the list of CAs and CRLs in directory
210922 15:13:00 2847809 TPC_Config: Using filesystem object from the framework.
Plugin loaded XrdMacaroons v5.3.1 from exthandlerlib libXrdMacaroons-5.so
210922 15:13:00 2847809 sysInitialize: Creating new Macaroon handler object
=====> continue /etc/xrootd/config.d/
Config continuing with file /etc/xrootd/config.d/10-xrootd-lcmaps.cfg ...
Config continuing with file /etc/xrootd/config.d/40-xrootd-lcmaps.cfg ...
Config continuing with file /etc/xrootd/config.d/60-osg-multiuser.cfg ...
Config continuing with file /etc/xrootd/config.d/99-local.cfg ...
=====> macaroons.secretkey /etc/xrootd/macaroon-secret
=====> all.sitename T2_US_Caltech

[juztas]

@djw8605 fyi

[abh3]

Yes, that's correct. One of the failings of the documentation is that it doesn't tell you whether a directive is replaceable, additive, or modifiable. Some are and some are not. So, I am not suprised here. The chksum directive is additive not replaceable and if you don't specify the job limit in a subsequent directive it changes to the default of 4.

[djw8605]

The multiuser plugin also reads the chksum line, and it is additive. I think it should be replaceable though, and Brian pointed out that the plugin needs to reset the calculated digests each time is sees the value.

Setting m_digests to 0 here:
https://github.com/opensciencegrid/xrootd-multiuser/blob/0e4e26c096719aa3923d6b9b6450b8a9836dbbff/src/MultiuserFileSystem.cc#L117

Completely untested pull request:
opensciencegrid/xrootd-multiuser#26

[abh3]

While I agree that some directives would be better handling a subsequent directive in a diffrent way, the problem is that it would make some config file out there no longer backward compatible if we change the existing behaviour. So, we are sort of suuck with only "gees wouldn't it better if...." as the practical resolution. Yes, we could add a special keyword indicating you want replacement but it's an enormous task going through the hundreds of existing directives to make them all consistent with that approach.

[juztas]

Solved here: opensciencegrid/xrootd-multiuser@aa4bca9