Re: [HTCondor-users] condor can't find its own program executable

[John M Knoeller <johnkn@xxxxxxxxxxx>]

If it is not a shell script, then 
/bin/sh /usr/pgsql-10/bin/psql

is expected to fail. 

Why it doesn't work when you tell HTCondor that /usr/pgsql-10/bin/psql is the executable, 
my best guess is that the environment is different between running the program yourself
and running as a local universe job.

try adding

setenv = true

to your submit file.  That will take pass the environment at submit time into the local universe job.

-tj


-----Original Message-----
From: Dimitri Maziuk <dmaziuk@xxxxxxxxxxxxx> 
Sent: Friday, March 29, 2019 11:51 AM
To: John M Knoeller <johnkn@xxxxxxxxxxx>; HTCondor-Users Mail List <htcondor-users@xxxxxxxxxxx>
Subject: Re: [HTCondor-users] condor can't find its own program executable

On 3/29/19 11:42 AM, John M Knoeller wrote:
> Maybe a problem with the path, or library path? perhaps some needed library isn't being found.
> is /usr/pgsql-10/bin/psql a shell script?

Not that I can see (these are all as web user: same as the one condor
job runs as):

> $ file /usr/pgsql-10/bin/psql
> /usr/pgsql-10/bin/psql: ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32,
BuildID[sha1]=80b2dcede3538df9a478cc2b94f358fa0a37d014, stripped

> $ ldd /usr/pgsql-10/bin/psql
> 	linux-vdso.so.1 =>  (0x00007ffcecf1a000)
> 	libpq.so.5 => /usr/pgsql-10/lib/libpq.so.5 (0x00007f89ff472000)
> 	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f89ff252000)
> 	libreadline.so.6 => /lib64/libreadline.so.6 (0x00007f89ff00a000)
> 	librt.so.1 => /lib64/librt.so.1 (0x00007f89fee02000)
> 	libm.so.6 => /lib64/libm.so.6 (0x00007f89feafa000)
> 	libc.so.6 => /lib64/libc.so.6 (0x00007f89fe72a000)
> 	libssl.so.10 => /lib64/libssl.so.10 (0x00007f89fe4b2000)
> 	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f89fe04a000)
> 	libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f89fddfa000)
> 	libldap_r-2.4.so.2 => /lib64/libldap_r-2.4.so.2 (0x00007f89fdb9a000)
> 	/lib64/ld-linux-x86-64.so.2 (0x00007f89ff6ba000)
> 	libtinfo.so.5 => /lib64/libtinfo.so.5 (0x00007f89fd96a000)
> 	libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f89fd67a000)
> 	libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f89fd472000)
> 	libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f89fd23a000)
> 	libdl.so.2 => /lib64/libdl.so.2 (0x00007f89fd032000)
> 	libz.so.1 => /lib64/libz.so.1 (0x00007f89fce1a000)
> 	libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f89fcc0a000)
> 	libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f89fca02000)
> 	libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f89fc7e2000)
> 	liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f89fc5d2000)
> 	libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f89fc3b2000)
> 	libssl3.so => /lib64/libssl3.so (0x00007f89fc15a000)
> 	libsmime3.so => /lib64/libsmime3.so (0x00007f89fbf32000)
> 	libnss3.so => /lib64/libnss3.so (0x00007f89fbc02000)
> 	libnssutil3.so => /lib64/libnssutil3.so (0x00007f89fb9d2000)
> 	libplds4.so => /lib64/libplds4.so (0x00007f89fb7ca000)
> 	libplc4.so => /lib64/libplc4.so (0x00007f89fb5c2000)
> 	libnspr4.so => /lib64/libnspr4.so (0x00007f89fb382000)
> 	libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f89fb15a000)
> 	libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f89faf22000)
> 	libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f89facba000)
> 	libfreebl3.so => /lib64/libfreebl3.so (0x00007f89faab2000)

CL run:

> $ psql -d bmrbeverything -U postgres -f /websites/webapi/wsgi/releases/v2/server/wsgi/utils/sql/initialize.sql
> psql:/websites/webapi/wsgi/releases/v2/server/wsgi/utils/sql/initialize.sql:5: NOTICE:  extension "pg_trgm" already exists, skipping
> CREATE EXTENSION
> DO
> CREATE FUNCTION
> DO
...

And looking at web's env, it has no LD_LIBRARY_PATH, LD_PRELOAD, or
anything of the sort. It doesn't even have /usr/pgsql-10/bin in $PATH,
it's all handled by /etc/alternatives.

-- 
Dimitri Maziuk
Programmer/sysadmin
BioMagResBank, UW-Madison -- http://www.bmrb.wisc.edu