HCL Domino Ideas Portal

Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.

For more information and upcoming events around #dominoforever, please visit our Destination Domino Page

Add a new idea Subscribe
Status Under Consideration
Workspace Notes
Created by Guest
Created on Sep 4, 2020

RELATED IDEAS

Avoid large dump files as ticking time bombs at macOS Notes clients

A crash at the macOS Notes client generates log files. Crash happens, log files are helpfull to fix the issue.

Beside the IBM_TECHNICAL_SUPPORT folder have a look at: .../HCL(or IBM) Notes Data/Expeditor/Applications/logs

(You might know, this Notes data path is hidden by default under /Users/[username]/Library/Application Support/)

We noticed a ticking time bomb there.

Every crash generates a large .dmp file and additional log data. This path is for the Java log files. The .dmp file correspond to the used memory during the crash. On a 8 GB RAM machine it grows to 10 GB .dmp file at ANY serious crash! This .dmp files also never get deleted. And they are hidden and can not be cleaned up easily buy a normal user.

As we all know, Apple sells often machines with much RAM and expensive ,as result, low disk capacities.

As result, macOS users with frequently crashes ran out of disc space sooner or later.

I suggest to take memory dumps not per default, only by a special 'debug' flag in some config file.

Thank you.

  • Attach files
  • Guest
    Reply
    |     Nov 5, 2020

    @Thomas: One of the last crashes kills the whole machine of a VIP. As said it eats up 55 GB disk space in one go. The .dmp files are in a hiidden area the user is not able to access. This is a showstopper for the entire computer. Sorry, this is not acceptable.

    Common are "debug" flags to analyze the next crash. The Notes client should be set in a debug mode for this.

    In addition, i do not see this behaviour at windows clients.

    For whom it may concern:

    We need to set:

    "kern.coredump=0" in "/etc/sysctl.conf" (this file does not exist an must be created with sudo permissions)

    Also in the Notes JVM configuration:

    "vmarg.Xdump=-Xdump:system:none" in "/Applications/HCL Notes/Contents/MacOS/rcp/depoly/jvm.properties"

    This will now avoid the large .dmp files.

    Thanks to the HCL support !

  • Guest
    Reply
    |     Oct 28, 2020

    Today one single crash generates 4 large dump files.

    1. at /cores/ 13 GB

    2. at .../(Notes data)/Expeditor/Applications/logs/ one Jil...dmp an two core...dmp file with 13 GB, 13 GB and 17 GB

    In result one Crash consumed 55 GB of disk space

    This is beside all the IBM_TECHNICAL_SUPPORT path. The crash logs here only 3 MB data.

    55 GB is 1/5 of the whole disk size in my example - consumed in one crash!

  • Admin
    Thomas Hampel
    Reply
    |     Sep 6, 2020

    If a memory dump would be taken only when a debug flag is set then it would not be possible to analyze one-time crashes.

Copyright © 2023 HCL Technologies Limited