savecrash file

[Kim wing]

Hi,

I've been having problems saving the system crash files after changing the defaul crash directory. I found out that the crash still goes to /var/adm/crash instead of /data/crash, the core dump doesn't start to create until I issue the command manually :
# savecrash -vr
I have checked the file /sbin/init.d/savecrash and the permission as well as the owner and group as following:
-r-xr-xr-x 1 root sys 3801 Jul 29 00:51 savecrash
Is this correct, should the owner and group be bin bin?
Please help.

[Kevin Wright]

you changed /etc/rc.config.d/savecrash?

What does crashconf -v show you?

[Kim wing]

Yes, I did changed the /etc/rc.config.d/savecrash
Here is the output of the crashconf -v
# crashconf -v
CLASS PAGES INCLUDED IN DUMP DESCRIPTION
-------- ---------- ---------------- -------------------------------------
UNUSED 319144 no, by default unused pages
USERPG 17664 no, by default user process pages
BCACHE 119167 no, by default buffer cache pages
KCODE 1762 no, by default kernel code pages
USTACK 766 yes, by default user process stacks
FSDATA 226 yes, by default file system metadata
KDDATA 34309 yes, by default kernel dynamic data
KSDATA 31246 yes, by default kernel static data

Total pages on system: 524284
Total pages included in dump: 66547

DEVICE OFFSET(kB) SIZE (kB) LOGICAL VOL. NAME
------------ ---------- ---------- ------------ -------------------------
31:0x016000 72544 2023424 64:0x000002 /dev/vg00/lvol2
31:0x015000 1024 2043904 64:0x000004 /dev/vg00/lvol4
----------
4067328
What's yout thoughts?

[Tim Adamson_1]

Hi,

As mentioned in a previous post, tou should change the file /etc/rc.config.d/savecrash. The variable to uncomment and change is SAVECRASH_DIR.

Then run
# /sbin/init.d/savecrash start

Obviously you should test by doing a TOC :-)

Also make sure that LOG_ONLY in the same file is NOT set to 1.


Cheers!!

[Vasikaran Venkatesan]

Try putting the option (-d ) in the savecrash command line of the /sbin/init.d/savecrash file.

Sure - u might have checked this - just a reminder - /data/crash is mounted at boot time from the fstab file.

[Kim wing]

Guys,

Could you please do an ll on the file /sbin/init.d/savecrash and post the output here.
Thanks
Points will be asigned!!!

[Tim Adamson_1]

Hi,

Again, I would like to pint out that you should not change the /sbin/init.d/savecrash file. Changes should be made to /etc/rc.config.d/savecrash as I outlined in my earlier post.

Here is the ll output on my server:

# ll /sbin/init.d/savecrash
-r-xr-xr-x 1 bin bin 4037 Oct 22 1999 /sbin/init.d/savecrash

Cheers!!

[Steven E. Protter]

I have different output from ll

-r--r--r-- 1 bin bin 2318 Nov 14 2000 savecrash


Here is my file as a reference. Attached.

SEP

[Con O'Kelly]

Hi

Your permissions on savecrash are OK, though generally owner & group is bin. Mine are:
-r-xr-xr-x 1 bin bin 4037 Oct 22 1999 savecrash

Can you post /etc/rc.config.d/savecrash and
also output of:
# bdf /data/crash
# ll /etc/rc.config.d/save*

Cheers
Con

[Kim wing]

Tim,
Did you go thru my questions in my profile, you should see what S.K. Chan stated in his answers to my questions, I don't mean to offend you but I'm trying to understand so I would appreciate more explanation.

Steven,
I'm not worry about the permission but I'm worry about the owner and group which seemed to be incorrect in my output.I'll correct it, maybe that's why the crash files don't create at bootup.
Also your attached file is not uncommented.
I have the following lines uncommented in my /etc/rc.config.d/savecrash
SAVECRASH=1
SAVECRASH_DIR=/data/crash
Please keep posting your thoughts.

[Kim wing]

sorry Con, it seems we post at the same time.
Here is the ll /etc/rc.config.d/savecrash
-r--r--r-- 1 root sys 2188 Jun 5 05:46 savecrash

The owner and group is again incorrect.I'll correct and I hope this will fix the problem.
I wouldn't worry about the bdf /data/crash because I run everything manually, I also run the Q4 analyze and there was nothing in the dump because the system crashed yesterday and I guess the core dump is not the dump primary swap anymore.

Any thoughts.

[Tim Adamson_1]

Hi Kim,

No offence taken. Just offering my advice.

I can't see any response from S K Chan unless it was on a previous thread which I haven't read.

I will assume you have made the necessary changes to /etc/rc.config.d/savecrash.

Did you also ensure that LOG_ONLY is NOT set to 1. See the bootom of the file in /etc/rc.config.d/savecrash.

[Kim wing]

Tim,

Appreciate your understanding. Please find the current configuration file as attached.

[Con O'Kelly]

Hi

One thing I noticed is that your /sbin/init.d/savecrash file was edited today?? Also look at the output for Tim & I, our /sbin/init.d/savecrash file is the same size ( I think SEP's output refers to /etc/rc.config.d/savecrash), yours is a different size??

In reference to your post about SK, you mention changing /sbin/init.d/savecrash.
I have to agree with Tim, that its possible your problem stems from an incorrect /sbin/init.d/savecrash file. Apologies if this is not the case.

I'd eliminate this possibility by copying a verison of /sbin/init.d/savecrash from another system that has not been modified. Your /etc/rc.config.d/savecrash looks OK.

One other possibility is to just go back to all the default settings and mount /var/adm/crash to the logical volume that /data/crash uses. In that way you don't have to mess around with any settings.

Cheers
Con

[Tim Adamson_1]

Hi Kim,

Thanks for the file. It look good.

Other things to check:

In /stand/system, is there an entry saying:

dump lvol

If not, add it in and regenerate the kernel and reboot.

What does lvlnboot -v /dev/vg00 show?

What version of the OS are we talking about? There have been patches for TOC problems.

On earlier versions of HP-UX, a dump had to be part of vg00. Where is /data/crash?


Just some more ideas.

[Tim Adamson_1]

Hi Kim,

Thanks for the file. It look good.

Other things to check:

In /stand/system, is there an entry saying:

dump lvol

If not, add it in and regenerate the kernel and reboot.

What does lvlnboot -v /dev/vg00 show?

What version of the OS are we talking about? There have been patches for TOC problems.

On earlier versions of HP-UX, a dump had to be part of vg00. Where is /data/crash?


Just some more ideas.

[Tim Adamson_1]

Hi Kim,

If this gets posted multiple times, I apologise. I'm having trouble with IE now :(

Thanks for the file. It look good.

Other things to check:

In /stand/system, is there an entry saying:

dump lvol

If not, add it in and regenerate the kernel and reboot.

What does lvlnboot -v /dev/vg00 show?

What version of the OS are we talking about? There have been patches for TOC problems.

On earlier versions of HP-UX, a dump had to be part of vg00. Where is /data/crash?


Just some more ideas.

[Kim wing]

Con,

You are right about the file has been edited today to change the owner:group to bin:bin, that's all but you are wrong about the file itself, for this file is located at /etc/rc.config.d/ and not /sbin/init.d

Tim,
We are talking about 11.00

Here is where the dump located. No, it's not part of the vg00, it's part of the /dev/data/data file system.

an out put from the lvlnboot -v
# lvlnboot -v
Boot Definitions for Volume Group /dev/vg00:
Physical Volumes belonging in Root Volume Grou
/dev/dsk/c1t6d0 (10/0.6.0) -- Boot Dis
/dev/dsk/c1t5d0 (10/0.5.0)
Boot: lvol1 on: /dev/dsk/c1t6d0
Root: lvol3 on: /dev/dsk/c1t6d0
Swap: lvol2 on: /dev/dsk/c1t6d0
Dump: lvol2 on: /dev/dsk/c1t6d0, 0
Dump: lvol4 on: /dev/dsk/c1t5d0, 1

And yes, there is an entry for dump lvol in the /stand/system.
Please keep thinking.
Thanks

[Tim Adamson_1]

Hi Kim,

Looking at your listing of /sbin/init.d/savecrash, it shows you have been modifying it.

When a system boots, it will source ALL the files in /etc/rc.config.d directory to setup all the variables (thats why you shouldn't keep backup files in that directory). As the system steps through each run level, it will run the appropriate script in /sbin/rc?.d with a start parameter. The scripts are really just symbolic links to the real files in /sbin/init.d directory. Thats why you shouldn't make changes to files in /sbin/init.d.

So as Con said, put the file back as it was and make any changes to /etc/rc.config.d/savecrash.

Hope this helps to explain a little.

[Tim Adamson_1]

Hi Kim,

I think the problem is caused by the new crash directory being in a different VG. Why not prove it by doing the following:

Change /etc/rc.config.d/savecrash:

SAVECRASH_DIR=/var/adm/kim <<< new directory in vg00

# mkdir /var/adm/kim

# /sbin/init.d/savecrash start

Now see what happens when you TOC or try to save a crash dump. Does it go to /var/adm/kim??


Easy to test!!!

[Kim wing]

So you are saying that the /sbin/init.d/savecrash should still have the same old variables which is the dafualt one
/var/adm/crash whereas the /etc/rc.config.d/savecrash can have the new directory. I just don't understand how the system will ignore the /sbin/init.d/savecrash when it is the startup script?

[Con O'Kelly]

Hi Kim

I think there is some confusion creeping in.

Your original post stated /sbin/init.d/savecrash:
" I have checked the file /sbin/init.d/savecrash and the permission as well as the owner and group as following:
-r-xr-xr-x 1 root sys 3801 Jul 29 00:51 savecrash"
Its from this I deduce you have edited the file. Changing the owner to bin will not update the timestamp you see from an 'll' command.

Later in the thread you asked for people to post permissions on /sbin/init.d/savecrash, which myself & Tim did.

I'm sure you're aware but just to clarify, there are 2 files with the same name:
/sbin/init.d/savecrash
/etc/rc.config.d/savecrash.

You should only edit /etc/rc.config.d/savecrash as Tim said earlier in the thread.
When /sbin/init.d/savecrash runs it sources the variables from /etc/rc.config.d/savecrash.

I would also examine why you do not use the default /var/adm/crash and just mount this as another filesystem.

Cheers
Con

[Tim Adamson_1]

Hi Kim,

The /sbin/init.d/savecrash is a script that sets up the crash dump. However, it gets all its configuration information from /etc/rc.config.d/savecrash. So if you want to change the directory where the crash dump is saved, change the /etc/rc.config.d/savecrash file. Don't change the /sbin/init.d/savecrash script.

Have a look at the /sbin/init.d/savecrash script:

# more /sbin/init.d./savecrash
...

...
'start')
if [ -f /etc/rc.config.d/savecore ] ; then
. /etc/rc.config.d/savecore
fi
if [ -f /etc/rc.config.d/savecrash ] ; then
. /etc/rc.config.d/savecrash
...
...


The above line is saying, if there is a file called savecrash in /etc/rc.config.d directory, then source it into the current process (that why you have the . /etc/rc.config.d/savecrash bit)

So when it sources the /etc/rc.config.d/savecrash file, it will setup the SAVECRASH_DIR variable to be whatever you set it to.

Hope it helps

[Kim wing]

I'm getting confused now. Sorry but here is the current files listing, it this correct. Also please note that I always make a copy before any changes:

ll /etc/rc.config.d/sa*
-r--r--r-- 1 bin bin 2188 Jun 5 05:46 savecrash

ll /sbin/init.d/sa*
-r-xr-xr-x 1 bin bin 3802 Jul 29 04:59 /sbin/init.d/savecrash

Are the above correct, any changes should be done. I also changed the /sbin/init.d/savecrash back to the default one.

Thanks again.