Boot Script Oddities

Hello everyone,

I've got a RedHat ES 4.8 running on HP Hardware. I'm having an issue
with the postgresql startup script and I can't seem to sort it out.
For note, the version of postgresql is 7.4.19 and it is the version
that comes with RedHat 4.8.

When the system boots, the postgresql script fails to run.
As root, if I go to /etc/init.d and type './postgresql' start, it
fails
As root, if I go to /etc/init.d and type 'sh postgresql start', it
works
I've run it with debugging on (added 'set -x' at the top of the script
and 'set +x' at the bottom) and have found no real difference. The
command to start postmaster returns a failure when not run with 'sh'
before.
I've copied the script from a working system and it fails in a similar
way

Anyone have any thoughts?

Thanks,
Steven

On Mon, 28 Sep 2009, in the Usenet newsgroup linux.redhat, in article
<4b74f2d4-3895-4052-b871-74b5c7ae3d0c.TakeThisOut@o35g2000vbi.googlegroups.com>, Steven
wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

>When the system boots, the postgresql script fails to run.
>As root, if I go to /etc/init.d and type './postgresql' start, it
>fails

fails.... what happens exactly? Does the computer catch fire or somthin?

>As root, if I go to /etc/init.d and type 'sh postgresql start', it
>works

Environmental problem - not sure what because "it fails" doesn't convey
anything usable. Look at the script, and see that the shabang line
(the very first line in the script) is correct and the interpretor
specified (and any/all dependencies) is/are accessible when the script
tries to run. Also check the PATH, and permissions.

>I've copied the script from a working system and it fails in a similar
>way

On the working system where the script runs OK, run the command

'set > /some/filename'

and then repeat on the b0rken system. What's the difference? If you
can stop/start the daemon on a working system without having everyone
come after you with pitchforks and torches, add that 'set' line to the
top of the startup script and see what the environment is like when
starting there. Repeat on the b0rken system.

Probably overkill, but try 'strace -eopen /etc/init.d/postgresql start'
and wade through the resulting output (assuming you installed the strace
package).

[compton ~]$ whatis strace
strace (1) - trace system calls and signals
[compton ~]$

Another thought - on the working and b0rken systems, run the command
'rpm -qa > /some.other/file.name' and see if you are missing or
incompatible.

Old guy