Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Core dumps **in general**

    • Article Type: General
    • Product: Aleph
    • Product Version: 20

    Description:
    Systems discovered today that around 9:30/9:45 both the z39 and pc server were causing coredumps.

    In the /var/adm/messages file we see dumps starting around 9:30 AM. If they had continued, they could have destroyed the root file system.

    Resolution:
    Core files are created when the system `thinks` that the application terminates abnormally, and not necessarily when there is any actual functional problem.

    The size, location and names of core files can be controlled, on Sun Solaris machines, using the coreadm utility:
    (see http:http://prefetch.net/blog/index.php/2007/03/23/using-the-solaris-coreadm-utility-to-control-core-file-generation/).

    Since there are no reported functional problems in Aleph - we suggest that you change the core dump settings of the system, to avoid these core dumps.

    On our Solaris 9 machine we see coreadm settings:

    global core file pattern:
    init core file pattern: core
    global core dumps: disabled
    per-process core dumps: enabled
    global setid core dumps: disabled
    per-process setid core dumps: disabled
    global core dump logging: disabled

    while on your machine we see:

    global core file pattern: /var/core/core.%f.%p
    global core file content: all
    init core file pattern: core
    init core file content: default
    global core dumps: enabled
    per-process core dumps: enabled
    global setid core dumps: disabled
    per-process setid core dumps: disabled
    global core dump logging: enabled

    To disable the core dump use the -d options as described in man coreadm

    Please pay attention to the dump files in /var/core directory which are restricted to root only and can not be read without root privileges.

    Also, you can control core dump file size from the aleph environment by setting:
    limit coredumpsize 0

    Running the limit command on customer server shows that this parameter is already set to 0:
    apps-l-a18(1) >>limit
    cputime unlimited
    filesize unlimited
    datasize unlimited
    stacksize 8192 kbytes
    coredumpsize 0 kbytes
    vmemoryuse unlimited
    descriptors 64000


    This issue is still open and was escalated to Second line support for further analysis <2012-03-25 01:00:04>.
    This issue is still open and was escalated to Development for further investigation <2012-04-22 01:00:03>.


    • Article last edited: 10/8/2013
    • Was this article helpful?