SAS WIP not starting

[woo]

Hello Friends, 

I have SAS WIP data server not starting and log showing below error.

EDTLOG: could not bind IPv4 socket: address already in use 

EDTHINT: is another postmaster already running on port 9432? if not, wait for few seconds and retry. 

when i look at port 9432,

it shows that PID 36942/postgres process running 

when i perform ps -ef |grep 36942, there are multiple processes running. example, 

<id> 11592 36942  0  Sep24 ? 00:00:00 postgres: SharedServices SharedServices 10.68.89/89(28350) idle 

<id> 11602 36942  0  Sep24 ? 00:00:00 postgres: SharedServices SharedServices 10.68.89/89(28352) idle 

<id> 11606 36942  0  Sep24 ? 00:00:00 postgres: SharedServices SharedServices 10.68.89/89(28354) idle 

<id> 24023 36942  0  Sep24 ? 00:00:00 postgres: PaltformWebServices PlatformWebServices 100.68.89/89(28584) idle 

<id> 24027 36942  0  Sep24 ? 00:00:00 postgres: PaltformWebServices PlatformWebServices 100.68.89/89(28586) idle

.

.

and so on

looks like port is being hit by many different processes? How to do this clean up and start SAS WIP Data Server? Thank you. 

[anuraagjv]

I would manually kill all the processes under the port 9432,  after that, try to start the WIP Data Server.

[jklaverstijn]

Please be cautious when killing database processes. Especially when using "kill -9" will yank the process and leave no room for an orderly shutdown. Your data may become damaged.

Before anything else ask yourself why Postgres is still running. Did something go wrong when stopping the services? Did you forget a step somewhere? Is postgres the only service that is still running? Maybe the metadata server or some spawners are also still there. A thorough review of your routines may prevent this from happening again.

Then try again stopping the environment using the sas.servers script. If that does not help (eg. pid files me already point to the wrong processes) use the scripting of postgres itself. Or use kill on the postrgres processes but not with -9 but with -TERM. That usually signals Postgres to initiate an orderly shutdown instead of brutally killing it. A kill -9 should always be your last resort.