Обсуждение: 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
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
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
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
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
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: > 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 > > > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly >
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: > 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 > > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) >
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.