Skip to content

mpm_event module management is not consistent #2555

Open
@chacunda

Description

@chacunda

Describe the Bug

If mpm_event is enabled with apache::mod::event, using apache::mpm::disable_mpm_event will not disable it. Internally, at least on Debian 12, it looks like the event and mpm_event modules are identical, aside from the mpm_event module specifically warning about conflicts with other MPM modules. As a result, I believe it is a bug that the module's method to enable the module is not compatible with the way to disable the module.

Note: I will add a pull request with a patch to fix this behavior; I wanted an issue to link it against.

Expected Behavior

The expected behavior is that the Puppet module can both enable or disable mpm_event, based on variables such as host facts.

Steps to Reproduce

Steps to reproduce the behavior:

  1. Apply a manifest to a system that includes mpm_event:
include apache::mod::event
  1. Later, apply a different manifest to the same system that disables the same module:
include apache::mpm::disable_mpm_event
  1. Module will still be enabled, as the class to enable uses the name without the mpm_ prefix, while the class to disable the module does use the mpm_ prefix.

Environment

  • Version 12.1
  • Platform Debian 12

Additional Context

The inconsistency is caused by the module being enabled with ${mpm} as `event``:

target => "${apache::mod_dir}/${mpm}.conf",

target => "${apache::mod_dir}/${mpm}.load",

While the module is disabled with:

$event_command = ['/usr/sbin/a2dismod', 'mpm_event']

This is inconsistent with prefork and worker, which are enabled and disabled without the mpm_ prefix.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions