Reverting the parsing method of the RTE script

[PawelPlesniak]

Description

Fixes issue #977

The recent changes for PMaaS re-parsed the RTE script path, which was not needed.

Also adds a safeguard against intermittent X11-related issues associated with the handling of the DISPLAY environment variable. The generally reported solution is to remove this environment variables, and the issues go away.

[jcfreeman2]

I created a test build from this, DRNCFD_DEV_260717_A9. However, as dunedaq on daq.fnal.gov, if I run

pytest -s -v $DAQSYSTEMTEST_SHARE/integtest/minimal_system_quick_test.py

...I still run into the issue where I see messages like

[2026/07/18 14:07:26 UTC] INFO       ssh_process_manager.py:322               drunc.process_manager.SSH_SHELL_process_manager    Process 'root-controller' (session: 'minimal', user: 'dunedaq') was terminated unexpectedly through the remote pid. Reported exit code: 127.

and

bash: line 1: drunc-controller: command not found

in log files like /tmp/pytest-of-dunedaq/pytest-17665/run0/log_dunedaq_minimal_ru-controller.txt.

[PawelPlesniak]

MSQT passed, the remainder of the integration tests were skipped as this is not needed

[emmuhamm]

Lets Gamble, Try Merging 👍

(msqt + pytest ran fine on srv 19 on 20 june nightly, and running a basic drunc session worked)

(also tested with multi users and multihosts with Pawel and that passed)

[PawelPlesniak]

For the interested reader, when using dbt-setup-release, the directory structure is slightly different to that of one created with dbt-create, which I was not aware of. Looking in the cvmfs release, one has

tree /cvmfs/dunedaq-development.opensciencegrid.org/nightly/NFD_DEV_260720_A9/ -L 1
/cvmfs/dunedaq-development.opensciencegrid.org/nightly/NFD_DEV_260720_A9/
├── daq_app_rte.sh
├── dbt-build-order.cmake
├── dbt-setup-release-env.sh
├── fddaq_build_spack_install.log
├── pyvenv_requirements.txt
├── sourcecode
├── spack-0.22.0
├── spack-installation -> spack-0.22.0
├── spec_fddaq_log.txt
└── venv.tar.gz

3 directories, 7 files

whereas when using dbt-create, one has

tree NFD_DEV_260720_A9/ -L 2
NFD_DEV_260720_A9/
├── build
├── cache
│   ├── patches
│   ├── providers
│   └── tags
├── dbt-workarea-constants.sh
├── env.sh
├── install
│   └── daq_app_rte.sh
├── log
├── pythoncode
│   └── drunc
└── sourcecode
    ├── CMakeGraphVizOptions.cmake
    ├── CMakeLists.txt
    └── dbt-build-order.cmake

10 directories, 6 files

The core difference is the additional directory install/, which was assuumed to be global by #888. When constructing the boot request using an area set up with dbt-setup-release, one has

  executable_and_arguments {
    exec: "source"
    args: "/cvmfs/dunedaq-development.opensciencegrid.org/nightly/NFD_DEV_260720_A9/install/daq_app_rte.sh"
  }

which simply does not exist. As this is a bash level command, its failure is not blocking and is not propagated, hence the remainder of the command continues to execute.

The changes made in this PR revert back to the old way of getting the RTE script.