dump시 back groud로 받기

bong-seok kim

dump시 back groud로 받기


여기 이용하시는 모든분들 새해복 많이 받으세요

다름이 아니라 덤프파일을 디스크로 저장할때 back ground로 어떻게 받는지 궁금해서여

이렇게 받으면 시스템이 multi-user mode로 된후 받으니

시스템 startup시간이 빨라 지잖아여.

/etc/rc.config.d/savecrash, crashconf

여기서 바꾸어 줘야 하나여.

기본적으로 setup해놓으면.


rc script에서 dump저장하면서 약 30 - 1시간 시간이 걸립니다.

이럴 해결할려면 어떻게 해야하나여

즉 부팅이 다되고.

login이 다된후 받을려면여..

즉 rc script가 다 실행된후 자동으로 dump가 받히도록 할려면 어떻게 해야 합니까.

dump를 disable하면 savecrash로 받을수 잇지만 자동으로 받게 할려면여?
1 응답 1

dump시 back groud로 받기

1. savecrash에서 dump를 save 못하게 설정 합니다.

2. 장애 발생 시dump 발생후 리부팅 되었을때 로긴후

/sbin/init.d/savecrash 명령을 이용하여 dump를

filesystem or tape 으로 save 할 수 있습니다.

아래 내용을 참조 하시면 됩니다.

Saving the Dump to the File System

Where are Dumps Located and How Does the Actual Dump Image

Look Like?

After the system has finished to write the whole or only parts of the dump to the dump

devices, the system reboots and automatically starts up again. When booting up, the system

starts a rc script to copy the dump into the file system.

For UX 10.01:

The rc script itself is /sbin/init.d/savecore. Much more important is the configuration

script, which can be found at /etc/rc.config.d/savecore. This one allows to set several

options to configure the way and the location where the dump is stored. The default location

is /var/adm/crash. Here the dump comprises of the kernel file, vmunix.n and a single, more

or less large, memory image called vmcore.n. The number n increases with the number of

crashes that the system has experienced so far. Savecore maintains the count of saved crashes

in a file called bounds that is too found in the dump directory. If you remove the bounds file,

the numbering scheme starts again at zero.

For UX 10.10, 10.20 and 10.30:

The rc scripts and configuration files are the same here as with 10.01. The crash dumps are

stored in directories named core.n, where n is a number that increases with the number of

dumps. The directory contains a INDEX file, a vmunix file and several core chunks named

core.n.m. Per default the core chunks are gzipped to save disk space.


Since HP-UX 10.10 the core is saved into different chunkfiles because with UX 10.10 it was not

possible to create files > 2GB whereas the new T-Class server could already be equiped with more

than 2GB physical memory.

Beginning with UX 10.20 the corefiles are compressed using gzip(1) by default if the space

in the crash directory is insufficient.

For UX 11.X:

The rc script itself is /sbin/init.d/savecrash. The configuration file is stored at

/etc/rc.config.d/savecrash. The default location is still /var/adm/crash with sub

directories named crash.n for every saved crash. We still have a INDEX and vmunix file, but

now have so called image files for every contiguous chunk of memory that needed to be

Chapter 10 Crash Dumps

April 2002 Chapter 10 / Page 10

saved. If the kernel contains loadable modules, those are copied to the dump directory too.

A important change introduced with 11.00 was the ability to save so called selective dumps.

We dump only memory pages that are really required for analysis. The required page classes

can be configured with the crashconf(1M) utility. The crashconf command can also be

used to find out how much dump space would be needed. Run it while your system is under

its normal or higher than normal workload. The space needed will vary depending on the

workload of the machine, so add another 25% or so to be safe. The total dump space should

meet or exceed this amount.

NOTE (11.X):

The reason for renaming "core" to "crash" is, that a coredump is usually written when an

application fails but not the whole system.

NOTE (11.X):

The most significant change compared to UX 10.X is the possibility of configuring selective

dumps. Dumps no longer contain the entire contents of physical memory. With memory sizes

growing in leaps and bounds, it's become critical that HP-UX dump only those parts of

physical memory which are considered useful in debugging a problem. By default you get a

core of approx. 5-40% of physical memory, varying with the state of the system at dumptime.

Configuration can be checked and modified with the crashconf utility:

# crashconf


-------- ---------- ---------------- -----------------------------

UNUSED 14253 no, by default unused pages

USERPG 23876 no, by default user process pages

BCACHE 129981 no, by default buffer cache pages

KCODE 2044 no, by default kernel code pages

USTACK 451 yes, by default user process stacks

FSDATA 753 yes, by default file system metadata

KDDATA 72447 yes, by default kernel dynamic data

KSDATA 17699 yes, by default kernel static data

Total pages on system: 261504

Total pages included in dump: 91350


------------ ---------- ---------- ------------ -----------------

31:0x006000 72544 524288 64:0x000002 /dev/vg00/lvol2



You can configure crash directory, compression mode, … in the appropriate configuration file


Here are the most important Options:

SAVE 1 = save a crashdump (default)

0 = do not save a crashdump

SAVE_DIR directory for the crashfiles. Default is /var/adm/crash

COMPRESS 0 = never compress

Chapter 10 Crash Dumps

April 2002 Chapter 10 / Page 11

1 = always compress

2 = compress in case of insufficient space in crasdirectory



explained in the comments of the config file.

Saving the Dump Manually

If the dump was not saved completely due to lack of space in the crash directory you have the

possibility to save the dump again.

The -r option (resave) need to be included when this is not the first time that savecrash runs.

# savecrash -v

There is also the possibility to save the dump directly to a DDS tape:

# savecrash -v -t /dev/rmt/0m

NOTE (11.X):

For UX 11.X you need the savecrash patch PHCO_19308 in order to have the -t option.