Skip to content

kdump.conf gets parsed over and over again #139

@prudo1

Description

@prudo1

Running debug=1 bash -x /usr/bin/kdumpctl restart 2>&1 | grep -c "kdump_get_conf_val " on my test system shows that kdump_get_conf_val is called many times during the start of the kdump.service. In particular (using the default kdump.conf) it is called 63 times when a rebuild of the kdump initrd is required, 53 times without rebuilding the kdump initrd and, 12 times with config force_no_rebuild enabled. Each time kdump_get_conf_val is called the whole kdump.conf is parsed. This can lead to performance regressions as reported in #134.

Fix this by moving over to only parse the config once and store it in a way so it can be accessed later again, like it is done in kdumpctl with the OPT array. The problem with this is that the config is needed in (at least) three different places, kdumpctl, the module-setup.sh and, kdump.sh within the kdump initrd.

My suggestion is to make use of the systemd-creds to pass the config to the kdump-capture.service. This could look something like this:

  1. Remove all uses of kdump_get_conf_val in kdumpctl only relying on the OPT array.
  2. Write the content of OPT to temporary files, with the option name as file name and the value as content of the file.
  3. Install the files to /etc/credstore/kdump in the kdump initrd.
  4. Add LoadCredential=kdump:/etc/credstore/kdump to kdump-capture.service
  5. In kdump.sh the config can be accesses by checking if the file $CREDENTIALS_DIRECTORY/kdump_<option> exists and then reading its content.

Benefits of using systemd-creds I see (besides reducing the number of times kdump.conf needs to be parsed)

  1. kdumpctl can easily change/update the config. E.g. it can add the -F or --num-threads option for makedumpfile. This would allow us to move some functionality from kdump.sh to kdumpctl. Making kdump.sh simpler, easier to predict and, ultimately easier to debug.
  2. For UKIs the kdump initrd cannot be rebuild to include the local config but systemd-creds can be passed to them.
  3. systemd-creds can be encrypted. Although this requires a TPM2 when the credential is supposed to be available in the initrd. See man systemd-creds for details.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions