dsprcd starts, but not the rest of the services

[denzilsyb]

Hallo all

Perhaps you guys can offer advice before I go the re-install route (well, thats after Ascential contacts me!)

This morning we edited the dsenv file to add parameters for the oracle 9 plug in. To enable the plug in, we need to restart the services. Because of previous experiences I neglected using the uv -admin -stop command because it did not work before. I opted to bring down the actual server and restart the server because this was the most reliable option (on previous occasions the server was bounced twice before starting the services successfully). So, not being one to stand in the way of tradition I also rebooted the server twice (because the ds services did not start first time round).

The only service that starts with the uv -admin -start is the dsrpcd daemon, which means you can connect. But, what does NOT come up is the uv services, so what is happening is DS client is connected to the dsrpcd but there is nothing to connect to.

Not having been through this before, I am suspecting the UV has been corrupted. But how would I regen the UV without being able to connect to the UV service?

so, what i see when i do start the service:

Code: Select all

# ps -ef | grep ds
    root  7450  7202  0 13:43:28 pts/7    0:00 grep ds
   dsadm  5671  5669  0 13:23:25 pts/1    0:00 -sh -a /log/dsadm.log.20041028.lubbef.pts.1
   dsadm  5673  5671  0 13:23:31 pts/1    0:00 -sh -a /log/dsadm.log.20041028.lubbef.pts.1
    root  7418     1  0 13:42:38 pts/7    0:00 /udd001/app/dsadm/Ascential/DataStage/DSEngine/bin/dsrpcd
   dsadm  5674  5673  0 13:23:31 pts/4    0:00 -ksh

# ps -ef | grep uv
    root  7452  7202  0 13:43:33 pts/7    0:00 grep uv

We have checked the logs and all that comes up is:

DataStage Engine 7.0.1.1 instance "ade" has been brought up.

no error message at all. We have done a truss on the dsrpcd service as well, but there is no abnormal message (not that I can see).

thanks guys

dnzl

[kcbland]

You need to verify that your dsenv file does not contain errors. The startup script parses this file and you probably have errors that are preventing it from correctly parsing.

I suggest you revert to your saved "before" copy and restart your services.

By the way, the reason services don't start again after simply recycling is because you have connected clients (netstat -a |grep ds on 7+, or netstat -a |grep uv on 7-) and the listener has to have all connections closed before services can restart. Make sure that prior to recycling services that all users get out and you have a clean listener list.

[denzilsyb]

Hi Ken

while waiting for response, i did somem checking and founf the following in the $DSHOME:

dsenv.errs.041028.124048

inside is the following:

Code: Select all

/udd001/app/dsadm/Ascential/DataStage/DSEngine/sample/ds.rc: etlprd01:#=etlprd01:#: not found
/udd001/app/dsadm/Ascential/DataStage/DSEngine/sample/ds.rc: etlprd01:#: is not an identifier

The edited part of the dsenv is as follows:

Code: Select all

###### ORACLE ENV VARIABLES #######
        ORACLE_SID=edwp
        export ORACLE_SID
        ORACLE_HOME=/udd001/app/oracle/product/9.2.0
        export ORACLE_HOME
        PATH=$PATH:$APT_ORCHHOME/bin:$ORACLE_HOME/bin
        export PATH
        TWO_TASK=edw1_edwp
        export TWO_TASK

        LD_LIBRARY_PAT=H$DSHOME/java/jre/lib/sparc/client:$DSHOME/java/jre/lib/sparc:`dirname $DSHOME`/branded_odbc/lib:$DSHOME/lib:$DSHOME/uvdlls:$LD_LIBRAR
Y_PATH:$ORACLE_HOME/lib:$LD_LIBRARY_PATH
        export LD_LIBRARY_PATH

and you will notice the LD_LIBRARY_PATH has serious abuse to it. I reverted to the previous version (ok, I deleted what we added) and still only the dsrpcd comes up. Herewith the old/new dsenv:

Code: Select all

        LD_LIBRARY_PATH=$DSHOME/java/jre/lib/sparc/client:$DSHOME/java/jre/lib/sparc:`dirname $DSHOME`/branded_odbc/lib:$DSHOME/lib:$DSHOME/uvdlls:$LD_LIBRAR
Y_PATH
        export LD_LIBRARY_PATH

anything look out of place there? I have removed all references to oracle for now.

dnzl

[denzilsyb]

Ken

We are back up again. It was, as suggested, the dsenv file.

Is there any reason though that

Code: Select all

ps -ef | grep uv

will not show any uv processes running? I am sure this used to be the case with DS6.0 - i.e. uv??? would be shown to run.

thanks

[kcbland]

Clients connect under the process names of dscs and dsapi in the ps table. Using netstat is one of the 2 required steps to making sure there are no active process, ps is the other. That has always been true, the issue is the constant renaming of processes from uvcs to dscs; from uvapi to dsapi; unircpd to uvrcpd to dsrcpd.