[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] Strange Schedd Behaviour
- Date: Tue, 06 Jul 2010 09:07:45 -0500 (CDT)
- From: Steven Timm <timm@xxxxxxxx>
- Subject: Re: [Condor-users] Strange Schedd Behaviour
If the condor_schedd is started as root, then when various
users submit jobs it will temporary change user id to the
submitting user, to create the files, etc. If it stays
stuck as a regular user for any length of time, though,
then something is wrong.. I suggest turning on at least
D_SECURITY of debug level in SCHEDD_DEBUG, and maybe D_FULLDEBUG,
that will log every time that it tries to change user.
Are you sure that your $(SPOOL) directory is writeable by
the various places that it needs to be, ditto the area where
the users standard output, standard error, and Userlog are kept?
I've seen the schedd get hung as a non-privileged user before
where the user logs were on a NFS volume that was having problems.
On Tue, 6 Jul 2010, Mark Wheeler wrote:
I have recently started using Condor and am having some strange behaviour. The schedd process is somehow being started as a user that isn't CONDOR. All the other processes are find .. just this one.
I moved the submission node to another machine and all was well, schedd started as the CONDOR user .. however, we started submitting jobs and again the schedd was restarted under a different user account. Even when I start the schedd process from the command line it starts as this other user.
Anyone know what determines what user accounts are used to start the daemons and how I might reset it.?
Thanks in advance,
Principal Software Engineer
This e-mail and any files transmitted with it are strictly confidential, may be privileged and are intended only for use by the addressee unless otherwise indicated. If you are not the intended recipient any use, dissemination, printing or copying is strictly prohibited and may be unlawful. If you have received this e-mail in error, please delete it immediately and contact the sender as soon as possible. Clearswift cannot be held liable for delays in receipt of an email or any errors in its content. Clearswift accepts no responsibility once an e-mail and any attachments leave us. Unless expressly stated, opinions in this message are those of the individual sender and not of Clearswift.
This email message has been inspected by Clearswift for inappropriate content and security threats.
To find out more about Clearswiftÿÿs solutions please visit www.clearswift.com
Steven C. Timm, Ph.D (630) 840-8525
Fermilab Computing Division, Scientific Computing Facilities,
Grid Facilities Department, FermiGrid Services Group, Assistant Group Leader.