No title

"Mehta, Ashok" wrote:

Hi All,

I am running postgres on RedHat Linux It was running fine and our sysadmin
added a scsi tape device to the kernel and rebooted the machine so the
postmaster was killed with -9 signal and after that when I start postmaster
I get
FATAL: StreamServerPort: bind() failed: Permission denied
Is another postmaster already running on that port?
If not, remove socket node (/tmp/.s.PGSQL.5432) and retry.
postmaster: cannot create UNIX stream port

I have rebooted the machine since then and there is no file in /tmp
directory to be removed. I am absolutly positive that another postmaster is
not running and that file does not exist.

Ummm.. Without being condescending, when you checked for the existence
of .s.PGSQL.5432, did you use a regular 'ls' or 'ls -l', or did you use
'ls -a' or 'ls -al'? I don't know how much unix experience you have,
but I remember the moment I learned about the Unix version of hidden
files...and the associated '-a' option to ls....

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Thu, Jul 27, 2000 at 12:18:23PM -0400, Mehta, Ashok wrote:

I am running postgres on RedHat Linux It was running fine and our sysadmin
added a scsi tape device to the kernel and rebooted the machine so the
postmaster was killed with -9 signal and after that when I start postmaster

did the sysadmin kill postmaster with -9 or reboot, or both.

reboot does not normally kill things off with a -9, depending on the system
it uses a progression of other nicer signals.

killing postmaster with -9 is bad, as it doesn't give the process any chance
to do shutdown/cleanup functions, which might include clearing the socket in
/tmp.

this might also explain why you got the error after kill -9/reboot, but didn't
get it after a normal reboot.

if your sysadmin is going around using "kill -9" as a standard shutdown method,
well, you might want to speak to them about this, as it isn't really a nice
way to deal with things.

I get
FATAL: StreamServerPort: bind() failed: Permission denied
Is another postmaster already running on that port?
If not, remove socket node (/tmp/.s.PGSQL.5432) and retry.
postmaster: cannot create UNIX stream port

I have rebooted the machine since then and there is no file in /tmp
directory to be removed. I am absolutly positive that another postmaster is
not running and that file does not exist.

Any suggestions would be appreciated.

Thanks
Ashok

--
[ Jim Mercer jim@reptiles.org +1 416 410-5633 ]
[ Reptilian Research -- Longer Life through Colder Blood ]
[ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ]

"Mehta, Ashok" <mehtaa@hmc.harvard.edu> writes:

I get
FATAL: StreamServerPort: bind() failed: Permission denied
Is another postmaster already running on that port?
If not, remove socket node (/tmp/.s.PGSQL.5432) and retry.
postmaster: cannot create UNIX stream port

Hmm. The advice about removing /tmp/.s.PGSQL.5432 is relevant for the
most common case, namely where a socket file's been left around from
the last postmaster run. And that's pretty much what I'd have expected
to happen after a kill -9 on the postmaster. But there's something
else going on here, because the kernel error code in that scenario is
normally EADDRINUSE ("Address already in use"). You seem to be getting
EACCES or possibly EPERM ("Permission denied"). That's not even listed
as a possible error for a Unix-socket bind() in my system's man page for
bind...

The first thought that comes to mind is that maybe /tmp is not
world-writable, though I'd think all sorts of stuff would be falling
over if that were true. Anyway you need to be thinking about
permissions problems.

regards, tom lane

Well, did you do a -ls -la /tmp ? The socket file is hidden.

You could try /etc/rc.d/init.d/postgresql status

to see is there any postmaster still running or ps ax | grep postm

Or simply /etc/rc.d/init.d/postgresql stop

And tell your sysadmin the last one is the correct way of shutting down
postgresql.

Jesus.

On Thu, 27 Jul 2000, Mehta, Ashok wrote:

Since this person isn't the sysadmin, we can speculate that he was
running it as himself, and thus there was no shutdown script in
/etc/rc.d/. So when the system shuts down it doesn't know how to shut
down postgres properly, sends it a TERM, and then a KILL.

Jim Mercer wrote: