Mailing List ArchivesAuthenticated access |
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesAuthenticated access |
|
|
Yes, for some reason my setup is not following the default behavior.
condor_submit -schedd does show all schedds.
I ran condor_submit -schedd -autoformat Name MyAddress and tried using the name and address of a schedd in condor_submit -name but the job was still submitted to another schedd.
Below is an example of condor_q:
seamew:condor coulter$ condor_q
-- Schedd: starlifter.xxx.xxx.xxx : <xxx.xxx.xxx.xxx:64271?... @ 02/05/20 14:50:30 OWNER BATCH_NAME SUBMITTED DONE RUN IDLE HOLD TOTAL JOB_IDS coulter ID: 1310 2/5 10:48 _ _ _ 1 1 1310.0 Total for query: 1 jobs; 0 completed, 0 removed, 0 idle, 0 running, 1 held, 0 suspended Total for coulter: 1 jobs; 0 completed, 0 removed, 0 idle, 0 running, 1 held, 0 suspended Total for all users: 15 jobs; 0 completed, 0 removed, 0 idle, 0 running, 15 held, 0 suspended seamew:condor coulter$ seamew:condor coulter$ condor_rm coulter All jobs of user "coulter" have been marked for removal seamew:condor coulter$ condor_q -- Schedd: canberra.xxx.xxx.xxx : <xxx.xxx.xxx.xxx:49241?... @ 02/05/20 14:48:16 OWNER BATCH_NAME SUBMITTED DONE RUN IDLE HOLD TOTAL JOB_IDS Total for query: 0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended Total for coulter: 0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended Total for all users: 14 jobs; 0 completed, 0 removed, 0 idle, 0 running, 14 held, 0 suspended As you can see, I am running the condor_q from seamew, but the first result shows the schedd located on starlifter and after running condor_rm the schedd changes to canberra.
I'm not sure how to set the environment variable _CONDOR_TOOL_DEBUG=D_COMMAND _condor_submit -debug -name <submitfile> I tried placing it in the submit file:
# Unix submit description file
# sleep.sub -- simple sleep job environment = _CONDOR_TOOL_DEBUG=D_COMMAND _condor_submit -debug -name /net/home/coulter/sleep.sub executable = sleep.sh log = /net/home/coulter/condor/sleep.log output = /net/home/coulter/condor/sleep.out error = /net/home/coulter/condor/sleep.error should_transfer_files = Yes when_to_transfer_output = ON_EXIT queue but I don't see any additional output in sleep.log so I don't think I'm doing that right. Here's the local config file all workstations with schedds share:
CONDOR_HOST=macdaddy.xxx.xxx.xxx
DAEMON_LIST=MASTER STARTD SCHEDD ALLOW_READ=* ALLOW_WRITE=* ALLOW_NEGOTIATOR = macdaddy.xxx.xxx.xxx CONDOR_IDS = 3055.8186 CONDOR_ADMIN = root@$(FULL_HOSTNAME) ALL_DEBUG = D_FULLDEBUG SCHEDD_HOST=$(FULL_HOSTNAME) USE_SHARED_PORT=FALSE SEC_DEFAULT_AUTHENTICATION = OPTIONAL SEC_DEFAULT_AUTHENTICATION_METHODS = CLAIMTOBE Thanks again for any suggestions you may have.
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> on behalf of John M Knoeller <johnkn@xxxxxxxxxxx>
Sent: Monday, February 3, 2020 11:31:35 AM To: HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx> Subject: [Non-DoD Source] Re: [HTCondor-users] Assistance Configuring Authentication That’s a bit surprising, the *default* behavior of condor_submit is to submit to the local schedd. configuring SCHEDD_HOST is normally something you do when you want to have it default to a non-local schedd instead.
What does
condor_status -schedd
show? It should be showing all of your schedds.
now try
condor_status -schedd -autoformat Name MyAddress
that should show the names and addresses of all of your schedds.
When you run “condor_submit -name” using the Name field from the condor_status output above, that should submit to the schedd of that name. It does that by doing the equivalent of that condor_status query.
You can add -debug to condor_submit, and set _CONDOR_TOOL_DEBUG environment variable to see a log of the communication, like this
_CONDOR_TOOL_DEBUG=D_COMMAND _condor_submit -debug -name <submitfile>
where <submitfile> is the name of your submit file. This will log what schedd it is actually talking to. Look for QMGMT_WRITE_CMD, that is the actual submit. There will likely be a command before that where it queries the collector to get the address of the schedd.
-tj
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of COULTER, JAMES A CTR USAF AFMC 96 SK/CCI via HTCondor-users
Thanks that’s very helpful. I am still having problems getting condor_submit to send jobs to the schedd running on the workstation it was submitted from. I have tried setting SCHEDD_HOST in the local config file as well as trying condor_submit –name <schedd_name>. No errors are reported but jobs are still submitted to one schedd only.
Any suggestions on what else I can try to force condor_submit to send the job to it’s own schedd and not another workstations?
Thank you!
Jim
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of John M Knoeller
condor_q -all
will show you the name of the local/default schedd (it’s at this top of the output)
condor_status -schedd
will show you the names of all of the schedd’s in your pool
-tj
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of COULTER, JAMES A CTR USAF AFMC 96 SK/CCI via HTCondor-users
Thanks for reply. SCHEDD_HOST is undefined. The documentation says it is set with name@hostname, but for the life of me I can't figure out what the schedd daemons' names are . I ran condor_submit -verbose, but I can't find a name attribute in the output. Can you tell me how to determine the name of the schedd?
Thanks,
Jim
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
on behalf of John M Knoeller <johnkn@xxxxxxxxxxx>
condor_submit decides what schedd to send jobs to by looking at
the -remote option passed on the command line the configured value of SCHEDD_HOST looking for a local schedd (the configuration variable SCHEDD_ADDRESS_FILE tells it where to look)
If you are talking to a non-local schedd unexpectedly, you should check your configuration for SCHEDD_HOST by running
condor_config_val -verbose SCHEDD_HOST
I should warn you that CLAIMTOBE is *very* dangerous in this context. CLAIMTOBE “authentication” allows any user to impersonate any other user. and since condor_submit can ask the schedd to run arbitrary code, CLAIMTOBE would let any user run code as any other user.
-tj
From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx>
On Behalf Of COULTER, JAMES A CTR USAF AFMC 96 SK/CCI via HTCondor-users
Hi Collin,
Thanks for the reply. FS_REMOTE_DIR does not seem to be recognized. Using CLAIMTOBE does allow one workstation to submit it's job to the other workstation's schedd. I can now submit jobs from both workstations.
I am curious how condor_submit determines which schedd to send a job to. Or is that maybe the negotiator on the master? I think the preferable way (at least for us) would be for condor_submit to send the job to the schedd on the workstation the job was sent from.
Thanks again!
Jim
I do not know how condor_submit determines which schedd to
>If the FS issue is that /tmp isn't available to the Schedd you can change On Wed, Jan 29, 2020 at 9:22 AM COULTER, JAMES A CTR USAF AFMC 96 SK/CCI
|