DAQInterface saves the names of a run's logfiles in the run record by looking in the directories where it determines the artdaq processes would have written them out. In the case of private subnets, this can cause issues - in SBND's case, a node might be listed as sbnd-daq33-priv in the boot file, but on that node, artdaq will write out logfiles into a subdirectory which contains the hostname "sbnd-daq33" - determined via the unistd.h function "gethostname" - rather than "sbnd-daq33-priv". DAQInterface should account for this possible discrepancy, perhaps by checking the value of the $HOSTNAME variable on the remote node.
This Issue's been resolved; it can be tested using the head of the feature/issue22785_better_logfile_locating branch, commit 88773c6f5cf99edfac8e7743271c794d228377d9
This issue has been migrated from https://cdcvs.fnal.gov/redmine/issues/22785 (FNAL account required) Originally created by @jcfreeman2 on 2019-06-20 19:53:06
DAQInterface saves the names of a run's logfiles in the run record by looking in the directories where it determines the artdaq processes would have written them out. In the case of private subnets, this can cause issues - in SBND's case, a node might be listed as sbnd-daq33-priv in the boot file, but on that node, artdaq will write out logfiles into a subdirectory which contains the hostname "sbnd-daq33" - determined via the unistd.h function "gethostname" - rather than "sbnd-daq33-priv". DAQInterface should account for this possible discrepancy, perhaps by checking the value of the $HOSTNAME variable on the remote node.