MC/SG environment problem?

[Thomas J. Harrold]

We are seeing an interesting problem with a legacy app running under HP-UX11i, and the latest MC/SG environement. (we don't see this problem in a similar 11.0 environment)

We thought it may be a network issue, and were working with HP support, but recent testing may point to the environment setup by SG when starting the package. It seems that some traps are not being set the same: if we bring up our app manually, all is well, and our application client can communicate as expected. When SG brings up the app, the app client establishes a connection to the server socket, and then hangs.

I'm not even sure where to start looking, but since we can get the app to run by starting it up manually, it's going to fall on the sysadmins to fix this one....

Any help is appreciated.

-tjh

[Sanjay_6]

Hi,

Is it possible the problem is associated with the profile of the user id that is bringing up the app. While bringing the app up using the SG script, the profile may not be getting exported, while if you run this app manually, the profile of the user id that is starting the app is used and the proper variables are set.

You can try to start this app using the
su - userid -c ". $HOME/.profile;script_to_start_job"

in the customer_defined_run_cmds.

Hope this helps.

Regds

[Thomas J. Harrold]

Here is some more info from our appl. dev. folks. Again, this is very reproducable problem, and is only a problem when the app is started via user defined startup from within MC/SG.

-tjh

> Testing last Friday afternoon related to virtual IP and custer startup, determined a possible
> SHELL script ownership issues.
>
> When the driver is started manually outside the (scripted) Startup process, the connections
> worked correctly. When the custer startup was issued manually in steps, things worked
> as well, but we currently do not understand why? I will leave details about this process
> to the admins.
>
> Basically, the SIGIO, would not fire on inbound data streams and tickling the driver with
> an outbound message would force a comm read.
>
> The reason why connections would succeed, is due to the method used in the TCPRS
> application at startup. The process waits in the select() call for the connection and
> accepts the connection, which does not require an signal interrupt to wakeup.
>
> However, once connected, then we hibernate, and SIGIO is required to signal the driver
> which may be related to the process group setting etc...

[Duncan Edmonstone]

Thomas,

It's difficult to help without seeing how you start your app in Serviceguard - seeing the scripts and where you hook into the SG control scripts. In the meantime, following up on the thought that your process is not acting on a SIGIO as expected, this is presumably because it is not a member of the same process group as the socket, although why this would be the case when started ina different fashion I'm not sure... have a read of the following for a better understanding of the underlying code in this configuration:

http://docs.hp.com/en/B2355-90136/ch03s03.html

HTH

Duncan

[Thomas J. Harrold]

How can I determine the process group (pgrp)?

-tjh

[Duncan Edmonstone]

For a given process, ps will show you if used correctly:

UNIX95= ps -eo pid,args,pgid

For a given socket, I think lsof will show you:

http://hpux.connect.org.uk/hppd/hpux/Sysadmin/lsof-4.73/

HTH

Duncan