Silly problem with simple script

[Christopher McCray_1]

I have a simple little script that runs every Sunday that does nothing more than a check_recovery and mails the results. It runs fine on every server I have except for an L2000, which produces the message:

./mail.check.recov[18]: 7012 Memory fault(coredump)

Now, the job still runs and I get my mail as does everyone else in the list, but what is with the message, since the systems is keeping mum (syslog, dmesg, etc.). I have 8Gb memory on the system. Thanks in advance for your replies,

Chris

[Helen French]

Chris,

I assume that the mail.check.recov is your script name. Can you post the exact line (no-18) which gives you error ?

Is that refers to a modem ?

HTH,
Shiju

[MANOJ SRIVASTAVA]

Hi Chris

This refers to line no. 18 of the script , if you can post the script may be it will help.



Manoj Srivastava

[Mark Greene_1]

what is on line 18 of your script? also, what o/s version? it could be something as simple as an environment variable or a kernel parameter.

have you used the "strings" command to look at the core file for any clues?

mark

[harry d brown jr]

Chris,

What is mail.check.recov doing? What does your swapinfo return, and what are your kernel parameters set to?

live free or die
harry

[John Palmer]

If you can locate the core dump, 'file core' will tell you what program failed.

The [18] refers to line 18 in your script (but this can be misleading if you use shell functions).

If the above fail, then it's time to start introducing some logging in your script to indicate which bit is failing.

Regards,
John

[Christopher McCray_1]

Here you go:

/opt/ignite/bin/check_recovery >> /usr/local/bin/chk_rec_results 2>&1

Thanks for the quick reply

Chris

[James Beamish-White]

I know this might be a silly question, but does the directory /usr/local/bin exist, and is there enough file space on it?

Cheers,
james

[Christopher McCray_1]

Thanks John. Here is the output:

dmc29:/rootdir# file core
core: core file from 'check_recovery' - received SIGSEGV

[John Palmer]

So it's a bug in 'check_recovery'. I'd check your patches and/or the version of Ignite.

Regards,
John

[Helen French]

Hi Chris:

Some points:

1) Update your patch level to the latest.
2) Update the ignite software if you are using any old version.
3) Check the file existence - /var/opt/ignite/recovery/makrec.last

HTH,
Shiju

[Jeff Schussele]

Hi,

SIGSEGV errors are usually related to the maxssiz, maxdsiz or maxtsiz kernel parameters & don't forget the 64-bit entries if you're running 64-bit.

Rgds,
Jeff

[Christopher McCray_1]

Thanks guys for hanging in there with me. I checked out my patches with check_patches and cleared up a lot of conflicts (mainly with man permissions) and wound up removing a patch with errors. All this still hasn't cleared up my problem.

I have Installed the latest patches I am willing to install; meaning I used CPM and chose only critical, HP recommended patches and then others which had warnings with an HP recommended replacement.

As for the version of ignite, here are three servers:


dmc29:/var/adm/sw# swlist -l product |grep -i ignite
Ignite-UX B.2.6.358 HP-UX System Installation Services

dmc31:/var/adm/syslog# swlist -l product |grep -i ignite
Ignite-UX B.2.6.358 HP-UX System Installation Services

dmc39:/rootdir# swlist -l product |grep -i ignite
Ignite-UX B.2.4.307 HP-UX System Installation Services

Note: The first server is the one I am having problems with and the second two have not had any problems. Is the versions displayed dangerous versions and are in need of updating? I know that ignite is free and doesn't require a reboot, but I would like to see what the exact problem is and why it chose to act up now, rather than just chuck it and take the Microsoft approach.

I will take a look at the kernel parameters as well, Jeff, but like I said, this has just happened and I haven't made any changes except patch upgrades.

Is there anything else you can think of?

Chris

[Jeff Schussele]

Check to see if you have

PHNE_22244 (superseded by PHNE_25907) as it addresses:

"4. System panics due to instruction page fault.
5. 'netfmt' on 100BT traces causes SIGSEGV while running
HP_APA LAN_MONITOR"

HTH,
Jeff

[Helen French]

Hi Chris:

What happens if you run this command manually ? Are you getting some error in the standard output ?

# check_recovery

Updating the version can be a good solution. One of my system with latest patches and ignite version - B.3.6.82

HTH,
Shiju

[Christopher McCray_1]

Shiju -- same problem from the command line.
Jeff -- Have the patch installed, but again, have the same patch on various systems as part of my latest patch sweeps.

Gremlins???

Anyway, I will look into the ignite upgrade as well as patches, but I'm still irked.

[Helen French]

Hi Chris:

Again, noticed another thing: Are you making the tapes with make_recovery OR make_tape_recovery ? I think the check_recovery will be useful only if you use the make_recovery ( with -C ). The files used by these two commands are littlebit different. The make_tape_recovery writes log files under /var/opt/ignite/recovery/$date_time.

If you are using make_recovery, then I would suggest you to install latest ignite and use make_tape_recovery.

HTH,
Shiju

[pap]

Hi you need to update your ignite-UX software to latest version which is 3.x .
Get it from HP-UX site and download it.
This will definately solve your problem.

-pap