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 stop
sleep 10
$0 start
;;
*)
echo "Usage: postgresql {start|stop|status|restart}"
exit 1
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
-----------------------------------------------------------------
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
-----------------------------------------------------------------
Import Notes
Reply to msg id not found: 27947.984779910@sss.pgh.pa.us
"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,
iesu 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
-----------------------------------------------------------------
Attachments:
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,
iesu 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 directoryNow, 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 to the 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 user and
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 directories speci-
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/lib
the 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 insteadOur 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