Process overview differs on 'identical' systems

[Emiel van Grunsven]

I'm breaking my head over this and it should be so simple.
I've got 2 identical clusters, both running 11.0 and serviceguard 11.05. Running the same software as a package.
On one of these clusters, some application process show up in the procces table as:

/opt/osw/script_name.sh /opt/osw/script_name.sh

On the other cluster it shows up as:
/bin/sh /opt/osw/script_name.sh

I've left out the owner, pid etc from the info as I can't copy /paste from the system.

Can anybody help me out here?
Thank you so much

[Viktor Balogh]

you need to delve down into the serviceguard configuration, I suspect that the difference is coming from the control files. probably the script_name.sh was called differently on the clusters.

[Emiel van Grunsven]

Well.. that's why I initially also thought but that's all identical.
These scripts are run as a service and are all started equally (as script name)
The scripts are identical as well.

[Viktor Balogh]

then what about the default shell of the user who has this process running? or maybe a slight difference in his profile?

[Emiel van Grunsven]

thanks for your replies.

Process owner is root.
Shell's are the same, .profile is identical,
/etc/profile is identical

[Larry Klasmier]

is possible the process was stopped and restarted manaully on one of the systems?

[Emiel van Grunsven]

I can't exclude this but it's highly unlikely.
Next to these 2 clusters, there's 5 more of them that I didn't mention to keep the question clean and simple. It didn't seem to matter as these are all (7X) 2 node clusters and only 1 is having issues.

I really can't find any difference in these systems besides this one cluster where the processes seem to be running differently according to the processtable.
All config files, binaries, cluster files, profiles et cetera are identical.
What am I missing? ;)

[Viktor Balogh]

> I can't exclude this but it's highly unlikely.

just one more thought: you could check how long the process runs, and compare this to the timestamp you got from the package log. If there is a reasonable difference, somebody must have restarted that process...