Change condor configuration files order and add a new one
Condor RPM has a config file /etc/condor/config.d/00personal_condor.config that interferes with both the frontend and the factory configuration.
In the installation instructions we tell the admin to remove the file but a yum or rpm update that involves condor RPM will bring the file back.
The suggestion is to
1. add a new file overriding all the setting in /etc/condor/config.d/00personal_condor.config, /etc/condor/config.d/00personal_condor.config-override (see below for content) and
2. to change the name of all gwms files to come after other condor configuration files.
Either 1 or 2 are sufficient to solve the problem. Both of them would add more security.
The main problem are
that both come before 00personal_condor.config in lexicographic order.
I would suggest to start gwms configuration file names with 20_gwms, summing 20 to all the numbers, e.g.:
- cat /etc/condor/config.d/00personal_condor.config-override
- What machine is your central manager?
CONDOR_HOST = $(FULL_HOSTNAME)
- Set of confguration to override the personal condor config
COLLECTOR_NAME = ToOverride
START = FALSE
SUSPEND = FALSE
PREEMPT = FALSE
KILL = FALSE
DAEMON_LIST = MASTER
I tested this on a RPM installation with 3.2.2. This will do no harm and protect from the personal rpm config file.
The main interference is that if condor starts a startd, it takes over the jobs, so the most important line in the override is DAEMON_LIST = MASTER,
which is also in both 00_gwms_general.config and 00_gwms_factory_general.config
#5 Updated by Marco Mambelli over 5 years ago
The problem went away
The current HTCondor installation (8.2.7 from OSG) has no more 00_personal:
$ls /etc/condor/config.d/ 00-restart_peaceful.config 10-batch_gahp_blahp.config
Both those file do not start demons and do not interfere with the GlideinWMS installation.
This does not mean that future packagings of HTCondor will not reintroduce the problem.
The problem is actually there when installing condor.bosco (e.g. on a factory supporting batch submission) that includes "60-campus_factory.config" that starts the campusfactory daemons.
Given the limited case I will update the documentation instructing to remove the file and close this ticket.