Source not available error in a clustered environment

[jorgecox]

We have an issue with the Event Server (Mercator 6.7.1) in a clustered production environment.

Maps are unable to read files that are created by SAP and written to a NFS mounted drive e.g. /usr/sap/mercator.

The files look like this:

-rw-rw---- 1 prdadm sapsys 6323 Jan 31 23:01 PWS_1001_.222
-rw-rw---- 1 prdadm sapsys 511943 Jan 31 23:02 HRMDA_1001_.222

'mercator' is in the same 'group' as sapsys and is able to read/write the files when you log on as Mercator directly and look at the files from the /usr/sap/mercator directory.

If we change the owner and group of the files to mercator mercator then the map runs ok.

-rw-rw---- 1 mercator mercator 6323 Jan 31 23:01 PWS_1001_.222
-rw-rw---- 1 mercator mercator 511943 Jan 31 23:02 HRMDA_1001_.222

The production system is a clustered environment (2 servers, 1 active, 1 passive), running sun cluster 3.1 and the event server is started in a resource group and a script is run to set various environmental settings.

Although we get a map return 12, the log indicates that the file adapter has read the file successfully:-

<ExecutionSummary MapStatus="Error" mapreturn="12" ElapsedSec="0.028" BurstRestartCount="0">
<Message>Source not available</Message>
<CommandLine>/mercator/mercator/mercator6.7/mercator_data/transaction/HubMaps/SAP_INPUT_BATCH_VALIDATE.mmc -T -AEDU='%AuditLogDirectory%' -WU='%WorkFilesDirectory%' -IF1 /usr/sap/mercator/HRMDA_1001_.221 -IE2S113 %lt;data%gt; -IE3S3 %lt;data%gt; -IE4S1 %lt;data%gt; -IE5S166 %lt;data%gt; -IE6S2083 %lt;data%gt; -OE1 %lt;data%gt;</CommandLine>

<SourceReport card="1" adapter="File" bytes="23584" adapterreturn="0">
<Message>Data read successfully</Message>
<Settings>/usr/sap/mercator/HRMDA_1001_.221</Settings>
<TimeStamp>23:02:21 January 30, 2005</TimeStamp>
</SourceReport>


N.B.
· The SAP input file is NOT the map trigger
· The process works perfectly well in the non-clustered DEV/QA environments

Is anyone else out there using a Sun Unix clustered environment with event server?

Any assistance is greatly appreciated.

Jorgecox

 

[BocaBurger]

Since the data is read, I suspect that the card is set to delete on success, and when the time comes to delete the file, it is either gone, or locked by another application.

Since changing the ownership of the files solves the problem and there is no problem when the cluster software is not watching the files, I could be something required by the cluster as to permissions. Check with Sun on this.



BocaBurger
<===========================||////////////////|0
The pen is mightier than the sword, but the sword hurts more!

 

[jorgecox]

Thanks BocaBurger.

We have managed to workaround the problem, and I though I would let you know what we discovered.

We have diagnosed this further, by writing a map that calls a Unix script to run the "id -a" command. We found out that from within the clustered environment, the mercator user is not picking up any of the secondary groups (in this case mercators affiliation to the sapsys group).

Some Background information ...

In a clustered environment, from the root user, you activate the Mercator resource group which starts the mercator eventserver. The resource group runs a script supplied by mercator. This script uses 'su' command to change the user from root to mercator.

It seems that when you 'su' to mercator, the secondary groups in /etc/groups are not being recognised.

This problem, only happens in the clustered environment when you 'su' from a script (activated by starting the resource group) I.e. This is not a problem when 'su'ing from the command line, or from generally running a script.

We are talking to Sun about this to see if its a bug/and if there is a patch.

In the mean time we had two options.

1. To change the mercator group ID to equal the same group ID as sapsys (on the SAP box)

This is quite scary as there are over 100,000 files on the Mercator Production Server that would need to be changed.

2. Change the shared area on the SAP box such that when a file is written to it, it inherits an ACL which allows access to the Mercator group.

The later is the option we have chosen and it works fine.

Jorgecox