Skip to content

apache_httpd: reload fails on the Debian family because the deployed apache2.conf drops PidFile #338

Description

@NavidSassan

Bug description

On the Debian family the apache_httpd role deploys an apache2.conf that contains no PidFile directive. Debian's stock apache2.conf ships PidFile ${APACHE_PID_FILE}, so replacing it moves the PID file from /run/apache2/apache2.pid to Apache's compiled-in default /run/apache2.pid.

The running master was started by the package before the role swapped the config, so its PID is still in the old location. The next systemctl reload apache2 runs apachectl graceful, which looks up the PID file named by the current config, does not find it, concludes Apache is not running, and starts a second instance. That instance collides with the running one on port 80 and the handler fails:

(98)Address already in use: AH00072: could not bind to address [::]:80
(98)Address already in use: AH00072: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
AH00015: Unable to open logs
httpd not running, trying to start
Action 'graceful' failed.

apache2ctl -t reports Syntax OK throughout, so the configuration itself is valid. The role aborts at RUNNING HANDLER [linuxfabrik.lfops.apache_httpd : apache_httpd: systemctl reload httpd].

This affects the first run against a host, which is where the config swap happens. Once Apache has been restarted with the role's config the PID file matches again and reloads work, so the window closes on its own after a manual restart. Red Hat family hosts are unaffected: their reload handler is skipped because the restart handler has already run.

Steps to reproduce

  1. Run the apache_httpd role against a freshly installed Debian or Ubuntu host.
  2. The role installs the apache2 package, which starts the service with the packaged apache2.conf.
  3. The role overwrites apache2.conf.
  4. Any later task notifies the reload handler (for example Enable vHosts).
  5. The handler fails as shown above.

Confirming the mechanism on an affected host:

# the deployed config has no PidFile
grep -c PidFile /etc/apache2/apache2.conf
0

# so Apache uses the compiled-in default
apache2ctl -t -D DUMP_RUN_CFG | grep -i pid
PidFile: "/run/apache2.pid"

# but the running master wrote its PID where the packaged config pointed
cat /var/run/apache2/apache2.pid
2235

# a restart moves the PID file, after which reload works again
systemctl restart apache2
systemctl reload apache2

Expected behavior

The role's apache2.conf keeps the distribution's PidFile ${APACHE_PID_FILE} on the Debian family, so that the configured PID file, /etc/apache2/envvars, and the apachectl wrapper used by the unit's ExecReload all agree. Reloading then succeeds on the first run.

Environment

  • LFOps: main (2e755988)
  • Affected: Debian 12, Debian 13, Ubuntu 22.04, Ubuntu 24.04, Ubuntu 26.04
  • Not affected: Rocky 8, Rocky 9, Rocky 10
  • Apache: 2.4.68 (Debian)

Additional context

Found by the apache_httpd Molecule scenario, which fails on all five Debian-family targets and passes on all three Red Hat family targets.

The role has never carried a PidFile directive (grep -rn PidFile roles/apache_httpd/ returns nothing), so this is independent of any recent change to the role.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions