Changed just a few kernel parameters...and now we receive

[Christina Martin]

this error.

From the /etc/rc.log

Initialize loadable modules
Output from "/sbin/rc1.d/S112kminit start":
----------------------------
ERROR: Module registration failed.
EXIT CODE: 1
"/sbin/rc1.d/S112kminit start" FAILED


any ideas where to start? HP says patches look okay and all kernel modules...but something has to be wrong....obviously.

any help you can provide would be appreciated.

Lisa Meade

[Marvin Strong]

I think the errors are logged to /tmp/.loadmods_err{pid}

you might want to try to see if that exists it should tell you what is erroring.

[Jaime Bolanos Rojas.]

Christina,

Please check that you have the right run level on the system and then run this command to test:

/sbin/init.d/kminit start

Regards,

jaime.

[Peter Godron]

Hi,
as a last resort, edit the S112kminit script and change the log file destination in the register_mods routine from /dev/null to something else e.g.
$KMMODREG -r $KMC >> /tmp/log.log 2>&1

Then return code to original version!

[Steven E. Protter]

Shalom Lisa,

Change them back.

Schedule maintenance and change them one at a time to diagnose the problem.

Might want to post to us exactly WHAT parameters were changed. Someone might notice a no-no.

SEP

[Christina Martin]

.loadmods file doesn't exist on our system.

While running in multi-user mode (init4) and doing the /sbin/init.d/kminit start...receive the same error.


I was just reminded that as a work around for another problem this system is having (Informix DB won't come on line during a normal boot sequence) the site has had to resort to booting to single user mode, starting the database, and then doing an init4 to bring the system all the way up. Could this be causing the error?

[spex]

Lisa,

If you're able to determine which parameter(s) is preventing S112kminit from starting (by examining logfiles, etc.), change the errant parameter back, recompile, and test. Then make incremental changes to the parameter and test again. Repeat until you are satisfied with the setting and system performance.

If you're unable to pinpoint the errant parameter, you will need to revert to your previous kernel. If you kept a copy of it, use that. Otherwise, change the kernel parameters back to the last known-good configuration (hopefully you recorded this) and recompile. Then boot using the old parameters.

After this, change one parameter at a time, recompile, and test. You should be able to pinpoint which one is causing problems.

PCS

[Christina Martin]

Okay, the only parameter I set out to change was maxfiles. We increased them from 256 to 1024.

Would this have changed another parameter that may use this setting in it's formula?

[spex]

Lisa,

I thought you said you changed _a few_ kernel parameters. Did you change maxfiles_lim also?

# kmtune | grep -i maxfiles

will tell you if any dynamic parameters depend on maxfiles. However, I doubt this is the case.

For your reference, here's a description of the maxfiles parameter:

http://docs.hp.com/en/TKP-90202/re35.html?jumpid=reg_R1002_USEN

I would lower the value to 512, recompile, and try again. What is the reason you chose 1024?

PCS

[A. Clay Stephenson]

Changing maxfiles to 1024 should have had no impact although maxfiles should be <= maxfiles_lim (the hard per-process limit) and maxfiles_lim, in turn, should be <= nfile. Systems regularly run with values well above 1024.

I suspect that changing the kernel back will not fix the problem.

[Marvin Strong]

Are you 100% certain that this problem did not occur prior to changing that kernel parameter.

It seems very unlikely that changes maxfiles would result with this error.

[spex]

Lisa,

Check to see if /etc/rc.log.old contains the same error.

PCS

[Christina Martin]

nope, not sure at all.

We're grasping at straws here. We were pretty certain the maxfiles parameter didn't cause the problem, but since we can't find the solution to either of the problems we are experiencing. Thanks.

[Christina Martin]

Thank you for all of your help.

We increased the shmmax kernel parameter as Informix was grabbing everything it could, but it was still not enough.

Lisa Meade