Shared memory

[RPC WHQ UNIX Team]

I'm trying restart a failed tracker agent from IBMs OPC scheduling package on a K460 running 10.20. I have checked the ipcs output and see nothing owned by this process/owner yet it keeps failing a squawking about shared memory. All I have seen on the server in glance is that I'm requesting more shared memory than is available but I have this situation on several clones of this system and they run fine. Any ideas?

[A. Clay Stephenson]

Do an ipcs -ma and note the value in the nattach column. If this value is zero then it MAY be safe to remove the shmid via ipcrm; it all depends upon how the software was written as to whether it's safe to remove it.

Even if all the shared memory segments are removed you might still have the problem because the memory is so fragmented that no one contiguous chunk is large enough to grant the request. In that case, the easiest solution is to reboot. Hopefully, this application starts fairly early in the boot sequence so that large chunks of memory are available. Your problem is very common in 32-bit HP-UX's.

[Bill Hassell]

Shared memory is, well, shared. There is only one mapping space for 32bit programs (even when running on a 64bit kernel) and this map is shared with mempry mapped files, shared libraries and shared memory segments. Thus, when you stop and start various appications that use any of these features, holes may be created that are too small for some applications to use. The key is to start all the apps in an orderly manner and leave them running forever. Since many apps are not stable enough to do that, anogther approach is to install a supported version of HP-UX (11.11 for instance) and upgrade the OPC software to a compatible version. Ideally, the new version will be 64bits rather than 32bits, but if not, you can use memory windows to workaround the problems with 32bit apps and shared memory.

ipcs -bmop will show you the curent shared memory segments but will tell you nothing about whether an application like OPC can obtain it's desired shared memory segment(s). To see the shared memory map for 32bit apps, get a copy of shminfo from ftp://contrib:9unsupp8@hprc.external.hp.com/sysadmin/programs

[Elmar P. Kolkman]

Though you didn't recognise the shared memory block in the ipcs output, the message you get implies two possible problems:
1) the shared memory block still exists. Take a look at the NATTCH column in the ipcs -ma output and remove all shared memory segments that have a value of 0 () in this column.
2) you're out of shared memory. This could be the reason for the failing tracker agent: it tried to enlarge its shared memory segment, but you don't have that much available. You could look at your other servers with ipcs to see if the shared memory segment is the same size on all of them (ipcs -ma, the SEGSZ column). If not, this could very well be a cause of your problem. In that case you could try to increase the possible shared memory segment size for this server, but this requires a reboot!

[RPC WHQ UNIX Team]

Thanks for the help. The problem ended up being on the mainframe side of the scheduler and a tcp/ip goof up that led to an invalid tracker agent attempting to establish a connection between the two. So much for change management!