Cannot init shared memory and no diagnostics as to why

Last week the AIX administrator made some changes to a running AIX system (at the direction of a consultant doing a security audit). The admin is quite new and 'just changed a few things the consultant told me too'. He doesn't really understand all that he changed, nor does he remember all that he changed..... The long and short is that once they bounced AIX, Informix 7.22 won't come back up. There are NO dignostics written to the online or console log. Both are sent to files and as far as I can see from their date/time stamps, they're not even being touched. The only message is "Shared memory not initialized for INFORMIXSERVER 'mredapd'". As far as he remebers, no changes were made to anything in Informix. I've even tried putting up a small test instance just to see if I could get the engine up with a 'fresh' root. Same results. "Initializing, please wait..." then "Recovering, please wait..." then "Shared memory not initialized..." I've run through the normal Informix config files (onconfig, sqlhosts, hosts, and services) and have found nothing amiss. Is there anyplace else I can go for more information as to why I can't get the Shared Memory?

Usually this will be because of permission problems, possibably with the root chunk. If you run "oninit -v" you will go into verbose mode during startup. This will at least let you know where you are in the startup procedure when the initialization fails. If you capture this information, and give it to tech support, they will probably be able to steer you in the right direction. FProse wrote: > Last week the AIX administrator made some changes to a running AIX > system (at the direction of a consultant doing a security audit). The > admin is quite new and 'just changed a few things the consultant told > me too'. He doesn't really understand all that he changed, nor does > he remember all that he changed..... > > The long and short is that once they bounced AIX, Informix 7.22 won't > come back up. There are NO dignostics written to the online or > console log. Both are sent to files and as far as I can see from > their date/time stamps, they're not even being touched. > > The only message is "Shared memory not initialized for INFORMIXSERVER > 'mredapd'". As far as he remebers, no changes were made to anything > in Informix. > > I've even tried putting up a small test instance just to see if I > could get the engine up with a 'fresh' root. Same results. > "Initializing, please wait..." then "Recovering, please wait..." then > "Shared memory not initialized..." > > I've run through the normal Informix config files (onconfig, sqlhosts, > hosts, and services) and have found nothing amiss. > > Is there anyplace else I can go for more information as to why I can't > get the Shared Memory?

I though I would post a followup message so that other's might benefit from this 'mess'. While I can't put my finger on any one thing that KO'd Informix, there are several factors that (I think) contributed: In a post, Madison suggested running oninit with the "-v" option. I appreciate the tip. The diagnostics that resulted indicated that Informix was trying to create a file in /etc and failing. One of the things the admin changed was the permissions on /etc. By opening that back up Informix was no longer blocked at that point. The directory /INFORMIXTMP had been deleted and also could not be re-created by Informix on startup. What ever the Admin patched precluded the daemon 'portmapper' from running. It would die without a dignostic. I'm assuming that this may have something to do with the ports Informix listens to. I never did get a good diagnotics out of Informix indicating what was precluding the server from starting. As I mentioned in my previous post, online.log and console.log were never even touched. The resolution? We rebooted with a mksysb that had been created about three weeks ago. This caused some regressions as they hadn't made one before applying the patches and changes! So we're back up and running. The only thing that didn't some up automatically after the mksysb was the volume group definition for the clairon raid array. That had to be imported manually. The only definition I ever recieved from what these patches were designed to do was that these were 'security oriented to make the server ready to hook into the internet'.