 |
 |
@xrootd-dev well, the scenario that i have i mind is this: the xrootd configs is generated/regenerated/site-wide synchronized for the same time of service but the actual service is used/started on various machines/containers etc... so actually what is common is the xrootd functionality (same export/role/params) but the deployment could wildly differ, and this is usually tune by provisioning tools (like dropping a override file in system/my_service.d/ )
So, as long i can specify in the systemd unit where the files will be written is good enough for me.
and just to offer complete explanation: i recently deployed my first EOS and it is annoying like hell this :
[root@mgm ~]# ll /tmp | grep daemon
drwx------. 2 daemon daemon 4096 Apr 6 21:50 eos.mgm
drwx------. 4 daemon daemon 4096 Apr 7 09:50 mgm
drwx------. 4 daemon daemon 4096 Apr 7 14:43 mq
prw-r-----. 1 daemon daemon 0 Apr 11 01:20 ofsEvents
drwx------. 5 daemon daemon 4096 Apr 6 18:57 quarkdb1
drwx------. 5 daemon daemon 4096 Apr 6 18:57 quarkdb2
drwx------. 5 daemon daemon 4096 Apr 6 18:57 quarkdb3
-rw-r--r--. 1 daemon daemon 164 Apr 11 01:20 xrootd.anon.env
-rw-r--r--. 1 daemon daemon 145 Apr 9 02:20 xrootd.mgm.env
-rw-r--r--. 1 daemon daemon 138 Apr 7 17:04 xrootd.mq.env
-rw-r--r--. 1 daemon daemon 5 Apr 11 01:20 xrootd.pid
-rw-r--r--. 1 daemon daemon 178 Apr 11 01:25 xrootd.quarkdb1.env
as a side note, i think that if -b is not used the pid file is useless (unless used internally by xrootd)
—
You are receiving this because you were mentioned.
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