Serious environment problem with 7.2 on Solaris

Randall Perry <rgp@systame.com> writes:

LD_LIBRARY_PATH is set in root & postgres login script, but strange things
are happening with it. If I ssh into server using postgres account
LD_LIBRARY_PATH is set. But if I su postgres from another account it isn't,
though all other variables from login script are set ok.

Hm. Not sure about Solaris, but on HPUX plain "su postgres" does not
run postgres' login script. You have to do "su - postgres" to make that
happen. Perhaps Solaris has some similar distinction?

Another question that comes to mind is did you remember to "export
LD_LIBRARY_PATH" in the script.

If I switch back to 7.1.3, no problem.

Possibly the 7.1.3 build doesn't need libgcc (presumably because it was
compiled with Sun's compiler not gcc).

regards, tom lane

Tom Lane <tgl@sss.pgh.pa.us> writes:

Randall Perry <rgp@systame.com> writes:

LD_LIBRARY_PATH is set in root & postgres login script, but strange things
are happening with it. If I ssh into server using postgres account
LD_LIBRARY_PATH is set. But if I su postgres from another account it isn't,
though all other variables from login script are set ok.

Hm. Not sure about Solaris, but on HPUX plain "su postgres" does not
run postgres' login script. You have to do "su - postgres" to make that
happen. Perhaps Solaris has some similar distinction?

Solaris is paranoid. It will only read the profile files for 'su -
user' if the shell for the user is '/usr/bin/sh'. Nothing else is
allowed, or the profile file is not read.

At least this is true for Solaris 8, not sure about others.

Tomas

Not true, you have to create an /etc/shells file.
But this is a little off topic.

--------------example - /etc/shells --------
/bin/ksh
/bin/csh
/bin/bash
...etc...
------------- cut here ---------------

-----Original Message-----
From: Tomas Berndtsson [mailto:tomas@nocrew.org]
Sent: Monday, May 13, 2002 7:46 AM
To: Tom Lane
Cc: Randall Perry; pgsql-general@postgresql.org
Subject: Re: [GENERAL] Serious environment problem with 7.2 on Solaris

Tom Lane <tgl@sss.pgh.pa.us> writes:

Randall Perry <rgp@systame.com> writes:

LD_LIBRARY_PATH is set in root & postgres login script, but strange

things

are happening with it. If I ssh into server using postgres account
LD_LIBRARY_PATH is set. But if I su postgres from another account it

isn't,

though all other variables from login script are set ok.

Hm. Not sure about Solaris, but on HPUX plain "su postgres" does not
run postgres' login script. You have to do "su - postgres" to make that
happen. Perhaps Solaris has some similar distinction?

Solaris is paranoid. It will only read the profile files for 'su -
user' if the shell for the user is '/usr/bin/sh'. Nothing else is
allowed, or the profile file is not read.

At least this is true for Solaris 8, not sure about others.

Tomas

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

I tried running this command in my CRON job just before the script command:
setenv LD_LIBRARY_PATH
"/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib/sasl"

And got the error:

sh: setenv: not found

What shell does CRON use?

Sorry, I didn't really think about my previous reply, here are some more
thoughts.
We have had real problems setting the LD_LIBRARY_PATH and LD_RUN_PATH
variables as well. These need to be set in every environment (Perl DBI,
crontab, profile etc.) that calls ld.

USERS
$ su
Doesn't execute $HOME/.profile
Remote users, or those that login will execute the .profile

SO FOR CRONTAB
1. Set the variables in the crontab file as environment variables (I am told
you can do this at the start of the crontab file?, but I haven't tried it
yet).
2. Set the environment variable in the shell that includes postgresql
commands.

LD_RUN_PATH - I've had to set this at compile time when compiling Solaris 8
x86

Hope this helps,

David.

-----Original Message-----
From: Randall Perry [mailto:rgp@systame.com]
Sent: 11 May 2002 20:01
To: pgsql-general@postgresql.org
Subject: [GENERAL] Serious environment problem with 7.2 on Solaris

Having major trouble with LD_LIBRARY_PATH env variable under 7.2. Getting
the error:

ld.so.1: psql: fatal: libgcc_s.so.1: open failed: No such file or directory
Killed

When starting.

LD_LIBRARY_PATH is set in root & postgres login script, but strange things
are happening with it. If I ssh into server using postgres account
LD_LIBRARY_PATH is set. But if I su postgres from another account it isn't,
though all other variables from login script are set ok.

If I switch back to 7.1.3, no problem. Below are the situations where I can
and cannot connect.

Is there some PgSQL misconfiguration I'm missing, or could there have been
something wrong with the compile?

7.1.3:
no env problems

7.2:
root can connect
root cron jobs can't connect, libgcc_s.so.1: open failed
remote users can connect
sudo root can't connect, libgcc_s.so.1: open failed
su postgres can't connect, libgcc_s.so.1: open failed
ssh postgres can connect

--
Randy Perry
sysTame
Mac Consulting/Sales

phn 772.589.6449
mobile email help@systame.com

I'll answer my own question; bash syntax works:
LD_LIBRARY_PATH=/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib/sasl;
export LD_LIBRARY_PATH; <script command>

I'll have to precede each script that uses PgSQL with this to get it to work
with CRON (Unless someone knows a way to set env for all CRON jobs).

Now the next problem: setting the env for my CGI scripts! :(

I tried running this command in my CRON job just before the script command:
setenv LD_LIBRARY_PATH
"/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib/sasl"

And got the error:

sh: setenv: not found

What shell does CRON use?

--
Randy Perry
sysTame
Mac Consulting/Sales

phn 772.589.6449
mobile email help@systame.com

Ok, discovered that my 7.1.3 build does NOT require LD_LIBRARY_PATH -- but
7.2 does. This is why 7.1.3 wasn't a problem (it may have been built with
the Sun compiler; I'm asking my ISP guy, who originally setup the server,
about that -- I built 7.2 with gcc).

And also discovered that sudo'ing, running CRON jobs, and running CGI
scripts will not inherit user shell environemnts, so in these cases I have
to find a way to export variables when using 7.2.

I also tried setting DYNAMIC_LIBRARY_PATH var in postgresql.conf -- also
didn't work.

Is there any way to get env variables to appear in ALL environments, no
matter what, under Solaris? I tried setting LD_LIBRARY_PATH in /etc/profile
but that didn't work.

Having major trouble with LD_LIBRARY_PATH env variable under 7.2. Getting
the error:

ld.so.1: psql: fatal: libgcc_s.so.1: open failed: No such file or directory
Killed

When starting.

LD_LIBRARY_PATH is set in root & postgres login script, but strange things
are happening with it. If I ssh into server using postgres account
LD_LIBRARY_PATH is set. But if I su postgres from another account it isn't,
though all other variables from login script are set ok.

If I switch back to 7.1.3, no problem. Below are the situations where I can
and cannot connect.

Is there some PgSQL misconfiguration I'm missing, or could there have been
something wrong with the compile?

7.1.3:
no env problems

7.2:
root can connect
root cron jobs can't connect, libgcc_s.so.1: open failed
remote users can connect
sudo root can't connect, libgcc_s.so.1: open failed
su postgres can't connect, libgcc_s.so.1: open failed
ssh postgres can connect

--
Randy Perry
sysTame
Mac Consulting/Sales

phn 772.589.6449
mobile email help@systame.com

sh: means /bin/sh

Try putting it in a script and then make the cron run the script.

This way you will have contril over the shell / interpreter you wish to
use

HTH

Darren Ferguson

On Mon, 13 May 2002, Randall Perry wrote:

This may be a bad idea but you could try sourceing the /etc/profile
when running the script. This would theoretically give your environment
what was in the /etc/profile

May be a bad idea have never had to do it before

Just another 2 cents worth :-)

Darren Ferguson

On Mon, 13 May 2002, Randall Perry wrote:

Been getting help for this problem on the gcc list, and finally got a
solution that works for me. Hope it helps you too.

The last configure command I tried before I got the solution was:
setenv LDFLAGS="-L/usr/local/lib -Wl,-R/usr/local/lib"; ./configure
--with-libraries=/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib/sasl
--enable-syslog

Below is a private email from Peter Kurpis of gcc list, which solved the
problem. It involves editing the makefile directly after configure.

-------------------------------------------------------------------------

Yikes. I downloaded the postgres distribution, and tried configuring it
on a couple of systems with different environments. I wasn't able to
set things up properly with flags, and I'm not convinced the build system
is healthy, after the unusual problems I had. :-( (For one thing,
--without-gnu-ld and --with-gnu-ld=no didn't have the right effect:
the build was still using -rpath instead of -R .)

But here's what I suggest:

Run configure --enable-syslog

Afterward, in src/Makefile.port, which is the solaris-specific stuff,
replace:

ifeq ($(with_gnu_ld), yes)
export_dynamic = -Wl,-E
rpath = -Wl,-rpath,$(libdir)
else
rpath = -R$(libdir)
endif
shlib_symbolic = -Wl,-Bsymbolic

with:

rpath = -L/usr/local/pgsql/lib -L/usr/local/lib -L/usr/local/ssl/lib
-L/usr/local/lib/sasl -Wl-R/usr/local/pgsql/lib -Wl,-R/usr/local/lib
-Wl,-R/usr/local/ssl/lib -Wl-R/usr/local/lib/sasl
shlib_symbolic = -Wl,-Bsymbolic

In other words, hardwire what you want to accomplish, as a kludge. It's
ugly, but I think it ought to work. Note that /usr/local/pgsql/lib seems to
be a default install directory -- see libdir in src/Makefile.global .
Since you are not using --libdir (or other similar ones) I think this
ought to stay like this; this is the default situation.

You can check things by running

gmake -np | grep ^LINK

The -n disables making any changes to the file system, -p causes printing
of the internal definitions tables. This will tell you what the build
looks like -- probably a standard build. Then do

gmake -np | grep ^LDFLAGS

and this ought to show you what you want to see.

Let me know how it goes... If you still have problems, cut and past
a line from the actual build, or perhaps you can send a log:

gmake >& make.log

so I can take a look at how (i.e. with which options) builds went.