RE: [Condor-users] condor_submit wrapper

["Michael Yoder" <yoderm@xxxxxxxxxx>]

> I am running condor 6.7.7 and using group quotas on my condor cluster.
> Most jobs are submitted to this cluster using the Globus GRAM
interface
> and I have hacked the condor.pm to add a
> +AccountingGroup = "group_<group>.<user>"
> to the classad of all incoming jobs from the grid.  This has
> been working fine.
> (Note that the names of the accounting groups on my system correspond
to
> the unix group names of the users in the passwd file).
> 
> I am now trying to do the same for local jobs.  I've written
> the following perl wrapper for condor_submit, which successfully
> does submit the job to the local schedd and put it in the correct
> accounting group.  It is grabbing the username and groupname
> of the user on the fly.
> 
> [root@fngp-osg bin]# cat condor_submit_wrap.pl
> #!/export/osg/grid/vdt/bin/perl
>      my $realusername = (getpwuid($<))[0];
>      my $realgroupname = (getgrgid($())[0];
>      my $groupstring =  "+AccountingGroup =
> \"group_$realgroupname.$realusername\"";
>      my $systemstring =
"/export/osg/grid/condor/bin/condor_submit_real -a
> '$groupstring' @ARGV ";
>      system ($systemstring);
> 
> 
> ----------------
> But when I put this perl wrapper in the place of condor_submit and
> rename the condor_submit binary to condor_submit_real, all
> sorts of wierd things happen.

You will probably have to clarify what "all sorts of weird things" are
for us to be able to help you. :-)

> So--the first question-- should any such wrapper to condor_submit be
> returning the return code of the real condor_submit binary, and if so,
> how would this be done.

It won't matter to condor_submit, but it may be useful for debugging.
Perl's system() returns the program's exit status.  You may want to see
the output, however, and that can be found if you use the backtick
operator instead.  (Or you can get fancy with fork/exec/pipes and
redirecting IO.)

> Second question, is there anything else obvious I'm missing?

system() is probably fork/execing a shell, which is fork/execing
condor_submit.  If you're exporting variables in your .bash_profile (or
.cshrc, etc) then they'll be picked up by condor_submit.  So for example
if your current environment has "CONDOR_CONFIG=/foo/bar/condor_config",
but you've got "CONDOR_CONFIG=/other_foo/bar/condor_config" in your
.bash_profile (or equivalent) then condor_submit will actually use the
other_foo version.

At least, the above wasn't obvious to ME until I ran into this myself.
I don't know if it's related to your problem.

Mike Yoder
Principal Member of Technical Staff
Ask Mike: http://docs.optena.com
Direct  : +1.408.321.9000
Fax     : +1.408.321.9030
Mobile  : +1.408.497.7597
yoderm@xxxxxxxxxx

Optena Corporation
2860 Zanker Road, Suite 201
San Jose, CA 95134
http://www.optena.com