Thread: problems with startup script on upgrade
I just compiled and installed postgresql from the cvs (upgraded from 7.1beta5
becuase of some problems I had), followed the steps, and the database server
works great, but my startup scripts don't work anymore.
What the script has, works if I try to do it as postgres, but with a
su -l postgres -c 'command' as root it doesn't work.
This is the script (on Solaris 7):
#!/bin/bash
# postgresql This is the init script for starting up the PostgreSQL
# server
#
# chkconfig: 345 85 15
# description: Starts and stops the PostgreSQL backend daemon that handles \
# all database requests.
# processname: postmaster
#
# This script is slightly unusual in that the name of the daemon (postmaster)
# is not the same as the name of the subsystem (postgresql)
# See how we were called.
case "$1" in start)echo -n "Starting postgresql service: "su -l postgres -c '/dbs/postgres/bin/pg_ctl -o "-i" -D
/dbs/postgres/data/
start -l /dbs/postgres/sql.log';; stop)echo -n "Stopping postgresql service: "su -l postgres -c
'/dbs/postgres/bin/pg_ctl-m i -D /dbs/postgres/data stop'echo;; status)su -l postgres -c '/dbs/postgres/bin/pg_ctl -D
/dbs/postgres/data/status';; restart)$0 stopsleep 10$0 start;; *)echo "Usage: postgresql
{start|stop|status|restart}"exit1
esac
exit 0
--
System Administration: It's a dirty job,
but someone told me I had to do it.
-----------------------------------------------------------------
Martín Marqués email: martin@math.unl.edu.ar
Santa Fe - Argentina http://math.unl.edu.ar/~martin/
Administrador de sistemas en math.unl.edu.ar
-----------------------------------------------------------------
"Martin A. Marques" <martin@math.unl.edu.ar> writes:
> ... my startup scripts don't work anymore.
> What the script has, works if I try to do it as postgres, but with a
> su -l postgres -c 'command' as root it doesn't work.
Please define "doesn't work". What happens exactly? What messages
are produced?
regards, tom lane
El Vie 16 Mar 2001 17:46, Tom Lane escribió: > "Martin A. Marques" <martin@math.unl.edu.ar> writes: > > ... my startup scripts don't work anymore. > > What the script has, works if I try to do it as postgres, but with a > > su -l postgres -c 'command' as root it doesn't work. > > Please define "doesn't work". What happens exactly? What messages > are produced? root@ultra31 /space/pruebas/postgres-cvs # su postgres -c '/dbs/postgres/bin/pg_ctl -o "-i" -D /dbs/postgres/data/ start -l /dbs/postgres/sql.log' 19054 Killed postmaster successfully started root@ultra31 /space/pruebas/postgres-cvs # No postmaster after that! -- System Administration: It's a dirty job, but someone told me I had to do it. ----------------------------------------------------------------- Martín Marqués email: martin@math.unl.edu.ar Santa Fe - Argentina http://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -----------------------------------------------------------------
"Martin A. Marques" <martin@math.unl.edu.ar> writes:
>> Please define "doesn't work". What happens exactly? What messages
>> are produced?
> root@ultra31 /space/pruebas/postgres-cvs # su postgres -c
> '/dbs/postgres/bin/pg_ctl -o "-i" -D /dbs/postgres/data/ start -l
> /dbs/postgres/sql.log'
> 19054 Killed
> postmaster successfully started
> root@ultra31 /space/pruebas/postgres-cvs #
Hm, that 'Killed' looks suspicious. What shows up in the
/dbs/postgres/sql.log file?
regards, tom lane
"Martin A. Marques" <martin@math.unl.edu.ar> writes:
>> Hm, that 'Killed' looks suspicious. What shows up in the
>> /dbs/postgres/sql.log file?
> Nothing at all.
That's no help :-(. Please alter the command to trace the shell script,
ie
su postgres -c 'sh -x /dbs/postgres/bin/pg_ctl -o ... 2>tracefile'
and send the tracefile.
regards, tom lane
El Vie 16 Mar 2001 19:05, Tom Lane escribió: > "Martin A. Marques" <martin@math.unl.edu.ar> writes: > >> Hm, that 'Killed' looks suspicious. What shows up in the > >> /dbs/postgres/sql.log file? > > > > Nothing at all. > > That's no help :-(. Please alter the command to trace the shell script, > ie > > su postgres -c 'sh -x /dbs/postgres/bin/pg_ctl -o ... 2>tracefile' > > and send the tracefile. There it goes. -- System Administration: It's a dirty job, but someone told me I had to do it. ----------------------------------------------------------------- Martín Marqués email: martin@math.unl.edu.ar Santa Fe - Argentina http://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -----------------------------------------------------------------
El Vie 16 Mar 2001 18:58, escribiste: > "Martin A. Marques" <martin@math.unl.edu.ar> writes: > >> Please define "doesn't work". What happens exactly? What messages > >> are produced? > > > > root@ultra31 /space/pruebas/postgres-cvs # su postgres -c > > '/dbs/postgres/bin/pg_ctl -o "-i" -D /dbs/postgres/data/ start -l > > /dbs/postgres/sql.log' > > 19054 Killed > > postmaster successfully started > > root@ultra31 /space/pruebas/postgres-cvs # > > Hm, that 'Killed' looks suspicious. What shows up in the > /dbs/postgres/sql.log file? Nothing at all. -- System Administration: It's a dirty job, but someone told me I had to do it. ----------------------------------------------------------------- Martín Marqués email: martin@math.unl.edu.ar Santa Fe - Argentina http://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -----------------------------------------------------------------
El Vie 16 Mar 2001 19:05, Tom Lane escribió: > "Martin A. Marques" <martin@math.unl.edu.ar> writes: > >> Hm, that 'Killed' looks suspicious. What shows up in the > >> /dbs/postgres/sql.log file? > > > > Nothing at all. > > That's no help :-(. Please alter the command to trace the shell script, > ie > > su postgres -c 'sh -x /dbs/postgres/bin/pg_ctl -o ... 2>tracefile' > > and send the tracefile. Found something, but just can't get why it started happening. There was some log to the sql.log: ld.so.1: /dbs/postgres/bin/postmaster: fatal: libz.so: open failed: No such file or directory Now, libz.so is in the LD_LIBRARY_PATH of the postgres user, so why is it that Solaris doesn't load the .profile in the postgres directory. I'm astonished! -- System Administration: It's a dirty job, but someone told me I had to do it. ----------------------------------------------------------------- Martín Marqués email: martin@math.unl.edu.ar Santa Fe - Argentina http://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -----------------------------------------------------------------
"Martin A. Marques" <martin@math.unl.edu.ar> writes:
> Now, libz.so is in the LD_LIBRARY_PATH of the postgres user, so why is it
> that Solaris doesn't load the .profile in the postgres directory.
Ah, but is the LD_LIBRARY_PATH the same inside that su? A change of
environment might explain why this works "by hand" and not through su
...
regards, tom lane
El Vie 16 Mar 2001 19:35, Tom Lane escribió: > "Martin A. Marques" <martin@math.unl.edu.ar> writes: > > Now, libz.so is in the LD_LIBRARY_PATH of the postgres user, so why is it > > that Solaris doesn't load the .profile in the postgres directory. > > Ah, but is the LD_LIBRARY_PATH the same inside that su? A change of > environment might explain why this works "by hand" and not through su > ... This #$^%^*$%¤ Solaris!!!!!! Check this out, and tell me I shouldn't yell out at SUN: root@ultra31 / # su - postgres -c 'echo $PATH' /usr/bin: root@ultra31 / # su - postgres postgres@ultra31:~ > echo $PATH /usr/local/bin:/usr/local/gcc/bin:/usr/local/php/bin:/opt/sfw/bin:/usr/local/a2p/bin:/usr/local/sql/bin:/usr/ccs/bin:/bin:/usr/bin/X11:/usr/bin:/usr/ucb:/dbs/postgres/bin: postgres@ultra31:~ > logout root@ultra31 / # Can someone explain to why Solaris is doing that, and why did it start doing it after an upgrade? I have no words. -- System Administration: It's a dirty job, but someone told me I had to do it. ----------------------------------------------------------------- Martín Marqués email: martin@math.unl.edu.ar Santa Fe - Argentina http://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -----------------------------------------------------------------
> > Ah, but is the LD_LIBRARY_PATH the same inside that su? A change of
> > environment might explain why this works "by hand" and not through su
> > ...
> This #$^%^*$%¤ Solaris!!!!!!
> Check this out, and tell me I shouldn't yell out at SUN:
> root@ultra31 / # su - postgres -c 'echo $PATH'
> /usr/bin:
> root@ultra31 / # su - postgres
> postgres@ultra31:~ > echo $PATH
/usr/local/bin:/usr/local/gcc/bin:/usr/local/php/bin:/opt/sfw/bin:/usr/local/a2p/bin:/usr/local/sql/bin:/usr/ccs/bin:/bin:/usr/bin/X11:/usr/bin:/usr/ucb:/dbs/postgres/bin:
> postgres@ultra31:~ > logout
> root@ultra31 / #
> Can someone explain to why Solaris is doing that, and why did it start doing
> it after an upgrade? I have no words.
It may be that this is the first build of PostgreSQL which asks for
"libz.so", but that is just a guess.
Not sure about "after the upgrade", but I'll bet that the first (command
line) case does not have an attached terminal, while the second case,
where you actually connect to the session, does.
Does your .profile try doing some "terminal stuff"? Try adding echo's to
your .profile to verify that it start, and that it runs to completion...
Also, PATH is not relevant for finding libz.so, so you need to figure
out what (if anything) is happening to LD_LIBRARY_PATH.
- Thomas
Hi all
On Fri, 16 Mar 2001, Martin A. Marques wrote:
> ld.so.1: /dbs/postgres/bin/postmaster: fatal: libz.so: open failed: No such
> file or directory
>
> Now, libz.so is in the LD_LIBRARY_PATH of the postgres user, so why is it
> that Solaris doesn't load the .profile in the postgres directory.
The main trouble with all of this is that LD_LIBRARY_PATH is irrelevant
here.
From man ld.so.1:
SECURITY To prevent malicious dependency substitution or symbol interposition, some restrictions may apply
tothe evaluation of the dependencies of secure processes.
The runtime linker categorizes a process as secure if the user is not a super user, and either the real
userand effective user identifiers are not equal, or the real group and effective group identifiers are
not equal. See getuid(2), geteuid(2), getgid(2), and getegid(2).
If an LD_LIBRARY_PATH environment variable is in effect for a secure process, then only the trusted
directoriesspeci- fied by this variable will be used to augment the runtime linker's search rules.
Presently,the only trusted direc- tory known to the runtime linker is /usr/lib.
There are many way to solve the problem:the easy -- copy (or link) libz.so to /usr/libthe clean -- avoid using
LD_LIBRARY_PATH,use -R for linking instead
Regards,
ASK
Alexander Klimov writes: > There are many way to solve the problem: > the easy -- copy (or link) libz.so to /usr/lib > the clean -- avoid using LD_LIBRARY_PATH, use -R for linking instead Our makefiles are set up to use '-R' for linking. Does this not work as designed? -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
On Sun, 18 Mar 2001, Peter Eisentraut wrote: > Alexander Klimov writes: > > There are many way to solve the problem: > > the easy -- copy (or link) libz.so to /usr/lib > > the clean -- avoid using LD_LIBRARY_PATH, use -R for linking instead > > Our makefiles are set up to use '-R' for linking. Does this not work as > designed? It depends on what it was designed for :-) My guess is that currently there is only something like `-R/usr/local/pgsql' in linking, but not for locations of other libraries: libz, libssl, libcrypto, etc. I guess that Martin's case of running postgress as `secure application' is something unusual, but there is more usual case: if you run apache as root (to be able to bind it to port 80) and then use from perl libpq (compiled with ssl) you will definitely have a trouble -- ssl will not be found. Regards, ASK