Mailing List ArchivesPublic Access |
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}
|
Mailing List ArchivesPublic 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. Jim From: HTCondor-users <htcondor-users-bounces@xxxxxxxxxxx> On Behalf Of John M Knoeller 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 |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature