1829161 Members
9647 Online
109986 Solutions
New Discussion

Problem with sap.conf

 
Bruno Bossier_1
Regular Advisor

Problem with sap.conf

ServiceGuard 11.16
SGeSAP 3.10

I followed the instructions in the SGeSAP configuration guide. When executing cmcheckconf -k -v -C cluster.conf -P sap.conf

I get the error :

Parsing package file: /etc/cmcluster/PE1/sap.conf.

cmcheckconf : Error found in package file: /etc/cmcluster/PE1/sap.conf.
Error: Unknown keyword (DB=ORACLE) on line 34

When I put DB=ORACLE in comment, cmcheckconf complains about the next parameter which is CINR=00

Any ideas ?

Thanks,
Bruno
9 REPLIES 9
Carsten Krege
Honored Contributor

Re: Problem with sap.conf

It appears you are using the wrong file as an argument for cmapplyconf -P. You need the package configuration file for the package which is created by cmmakepkg -p .

sap.conf is the environment file which is parsed by the package control script.

Carsten
-------------------------------------------------------------------------------------------------
In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. -- HhGttG
Bruno Bossier_1
Regular Advisor

Re: Problem with sap.conf

Thanks a lot !!!! What a stupid mistake I made.

Other question : SAPCPE is not installed, so there is no ctrun directory under /usr/sap/SID/SYS/exe. This does not seem to be a problem, only that the start script of the cluster is trying to access ctrun through NFS. As SAPCPE is not installed, I did not install NFS server so there is no need for the start script trying to access this NFS server. How can this be avoided ?

Bruno
Geoff Wild
Honored Contributor

Re: Problem with sap.conf

Not using NFS?

I'm not too sure how you are doing that in SAP...SAP relies on NFS - in particular for /usr/sap/trans...

What do you have under /usr/sap/SID/SYS/exe?

I have:

dbg -> /sapmnt/SID/exe
opt
run -> dbg

Rgds...Geoff

Proverbs 3:5,6 Trust in the Lord with all your heart and lean not on your own understanding; in all your ways acknowledge him, and he will make all your paths straight.
Bruno Bossier_1
Regular Advisor

Re: Problem with sap.conf

I have same under /usr/sap/SID/SYS/exe.

NFS for /usr/sap/trans is handled seperately. This is part of a seperate vg build into a seperate package.

We have no application servers, so there was no need for the usuage of SAPCPE.

Bruno
Geoff Wild
Honored Contributor

Re: Problem with sap.conf

Okay...no app servers....and in sap.conf, no ASHOST(s) defined? nor any exports?

In your /etc/cmcluster/sap.functions, how is CTEXEDIR defined?

What I'm trying to get is, what is "SAPCPE"?

I can't find that anywhere in my scripts...

Rgds...Geoff
Proverbs 3:5,6 Trust in the Lord with all your heart and lean not on your own understanding; in all your ways acknowledge him, and he will make all your paths straight.
Carsten Krege
Honored Contributor

Re: Problem with sap.conf

The ctrun directory should only exist if you want to make use of sapcpe to have local executables. If you don't use local executables I wouldn't expect a problem - at least not in SGeSAP.

In sap.functions there are references to the ctrun directory in the variable CTEXEDIR, however, the script always tries to access EXEDIR first.

So, I'm not sure where the reference to the ctrun directory is that you mean, I don't thnk there is a problem in SGeSAP.

Geoff,

normally R/3 accesses the executables on the AS through NFS. If the CI package runs on the other node, this NFS mount is not available and i.e. logon as HPUX user adm will not work properly. Using sapcpe SAP offers a way of storing the executables locally on every AS. sapcpe makes sure that patches or upgrades are distributed to all AS on the next startup automatically.

Carsten
-------------------------------------------------------------------------------------------------
In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. -- HhGttG
Bruno Bossier_1
Regular Advisor

Re: Problem with sap.conf

Here a snapshot of the log file. As you can see, the start script first tries to access ctrun, but after some timeouts it continues and finally everyting comes up.

Aug 16 14:15:45 - Node "uxwon02": (sapdbci_main): Entering SGeSAP startDBCI runtime steps ...
Aug 16 14:15:45 - Node "uxwon02": (get_source): Found /etc/cmcluster.conf
Aug 16 14:15:45 - Node "uxwon02": (get_source): Found /etc/cmcluster/PE1/sap.conf
Aug 16 14:15:45 - Node "uxwon02": (get_source): Found /etc/cmcluster/sap.functions
Aug 16 14:15:45 - Node "uxwon02": (get_source): Found /etc/cmcluster/PE1/customer.functions
Aug 16 14:15:45 - Node "uxwon02": (check_version): TRACE POINT
Aug 16 14:15:45 - Node "uxwon02": (check_parameters): TRACE POINT
Aug 16 14:15:45 - Node "uxwon02": (check_debug): TRACE POINT
Aug 16 14:15:45 - Node "uxwon02": (check_access 10.6.64.73 /usr/sap/trans/bin): TRACE POINT
Aug 16 14:15:45 - Node "uxwon02": (watchdog): Watchdog initiated (PID: 848 Timeout: 60 secs)
Aug 16 14:15:45 - Node "uxwon02": (is_node_alive 10.6.64.73): TRACE POINT
Aug 16 14:15:46 - Node "uxwon02": (check_access): Testing HA NFS setup ...
Aug 16 14:15:46 - Node "uxwon02": (watchdog): Watchdog initiated (PID: 859 Timeout: 60 secs)
Aug 16 14:15:46 - Node "uxwon02": (check_access): /usr/sap/trans/bin accessible
Aug 16 14:15:46 - Node "uxwon02": (check_access 10.6.64.73 /usr/sap/PE1/SYS/exe/ctrun): TRACE POINT
Aug 16 14:15:46 - Node "uxwon02": (is_node_alive 10.6.64.73): TRACE POINT
Aug 16 14:15:46 - Node "uxwon02": (watchdog): Watchdog initiated (PID: 867 Timeout: 60 secs)
Aug 16 14:15:47 - Node "uxwon02": (check_access): Testing HA NFS setup ...
Aug 16 14:15:47 - Node "uxwon02": (watchdog): Watchdog initiated (PID: 878 Timeout: 60 secs)
Aug 16 14:15:47 - Node "uxwon02": (check_access): WARNING: /usr/sap/PE1/SYS/exe/ctrun not accessible
Aug 16 14:15:47 - Node "uxwon02": (check_access): Delay for 10 secs
Aug 16 14:15:57 - Node "uxwon02": (is_node_alive 10.6.64.73): TRACE POINT
Aug 16 14:15:57 - Node "uxwon02": (watchdog): Watchdog initiated (PID: 905 Timeout: 60 secs)
Aug 16 14:15:58 - Node "uxwon02": (check_access): Testing HA NFS setup ...
Aug 16 14:15:58 - Node "uxwon02": (watchdog): Watchdog initiated (PID: 916 Timeout: 60 secs)
Aug 16 14:15:58 - Node "uxwon02": (check_access): WARNING: /usr/sap/PE1/SYS/exe/ctrun not accessible
Aug 16 14:15:58 - Node "uxwon02": (check_access): Delay for 20 secs
Aug 16 14:16:18 - Node "uxwon02": (is_node_alive 10.6.64.73): TRACE POINT
Aug 16 14:16:18 - Node "uxwon02": (watchdog): Watchdog initiated (PID: 934 Timeout: 60 secs)
Aug 16 14:16:19 - Node "uxwon02": (check_access): Testing HA NFS setup ...
Aug 16 14:16:19 - Node "uxwon02": (watchdog): Watchdog initiated (PID: 945 Timeout: 60 secs)
Aug 16 14:16:19 - Node "uxwon02": (check_access): WARNING: /usr/sap/PE1/SYS/exe/ctrun not accessible
Aug 16 14:16:19 - Node "uxwon02": (check_access): Delay for 30 secs
Aug 16 14:16:49 - Node "uxwon02": (check_access): WARNING: Attempt to connect to NFS server 10.6.64.73 failed
Aug 16 14:16:49 - Node "uxwon02": (check_own_app): TRACE POINT
Aug 16 14:16:49 - Node "uxwon02": (stop_own_app 4): TRACE POINT
Aug 16 14:16:49 - Node "uxwon02": (stop_other_inst): TRACE POINT
Aug 16 14:16:49 - Node "uxwon02": (ci_remove_shmem forced_strict): TRACE POINT
Aug 16 14:16:49 - Node "uxwon02": (ci_remove_shmem): Removing shmem of DVEBMGS00 on uxwon02 using forced_strict cleanup policy
Aug 16 14:16:49 - Node "uxwon02": (app_remove_procs DVEBMGS 00): TRACE POINT
Aug 16 14:16:50 - Node "uxwon02": (app_remove_shmem): TRACE POINT
Aug 16 14:16:50 - Node "uxwon02": (start_addons_predb): TRACE POINT
Aug 16 14:16:50 - Node "uxwon02": (start_ORACLE_db): TRACE POINT
Aug 16 14:16:50 - Node "uxwon02": (ora_setenv): TRACE POINT
Aug 16 14:16:50 - Node "uxwon02": (ora_setenv): ORASID=orape1 ORACLE_SID=PE1 ORACLE_HOME=/oracle/PE1/817_64 SAPDATA_HOME=/oracle/PE1
Aug 16 14:16:50 - Node "uxwon02": (ora_check_config): TRACE POINT
Aug 16 14:16:50 - Node "uxwon02": (ora_stop_listener): TRACE POINT
Aug 16 14:16:50 - Node "uxwon02": (ora_stop_listener): tnslsnr LISTENER not running ... skipping step
Aug 16 14:16:50 - Node "uxwon02": (ora_remove_sgadef): TRACE POINT
Aug 16 14:16:50 - Node "uxwon02": (ora_remove_sgadef): /oracle/PE1/817_64/dbs/sgadefPE1.dbf not present
Aug 16 14:16:50 - Node "uxwon02": (ora_remove_sgadef): /oracle/PE1/817_64/dbs/sgadefPE1.ora not present
Aug 16 14:16:50 - Node "uxwon02": (ora_remove_sgadef): Remove temporary sockets
Aug 16 14:16:50 - Node "uxwon02": (ora_remove_brbackup): TRACE POINT
Aug 16 14:16:50 - Node "uxwon02": (ora_remove_brbackup): No cleanup needed
Aug 16 14:16:50 - Node "uxwon02": (ora_remove_shmem): TRACE POINT
Aug 16 14:16:50 - Node "uxwon02": (app_remove_shmem): TRACE POINT
Aug 16 14:16:50 - Node "uxwon02": (ora_start_listener): TRACE POINT
Aug 16 14:16:50 - Node "uxwon02": (ora_start_listener): Start oracle listener ...
Aug 16 14:16:51 - Node "uxwon02": (ora_start_listener): TNSLSNR for HPUX: Version 8.1.7.4.0 - Production
Aug 16 14:16:51 - Node "uxwon02": (ora_start_listener): System parameter file is /oracle/PE1/817_64/network/admin/listener.ora
Aug 16 14:16:51 - Node "uxwon02": (ora_start_listener): Log messages written to /oracle/PE1/817_64/network/log/listener.log
Aug 16 14:16:51 - Node "uxwon02": (ora_start_listener): Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=PE1.WORLD)))


Carsten Krege
Honored Contributor

Re: Problem with sap.conf

Ah, these checks are new in SGeSAP 3.10..

Why don't you comment out the line

check_access ${CTEXERELOC} "${CTEXEDIR}"

in function start_DB() in sapdbci.cntl? Since CTEXEDIR is really an optional directory (although probably 95% of all SGeSAP users have it), it is questionable that the check should be enforced anyway.

Carsten
-------------------------------------------------------------------------------------------------
In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. -- HhGttG
Bruno Bossier_1
Regular Advisor

Re: Problem with sap.conf

Excellent ! It works ...

Thanks,
Bruno