[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug 62697] New: `ExtendedStatus Off` directive when using mod_systemd causes systemctl to hang


            Bug ID: 62697
           Summary: `ExtendedStatus Off` directive when using mod_systemd
                    causes systemctl to hang
           Product: Apache httpd-2
           Version: 2.5-HEAD
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Other Modules
          Assignee: bugs@xxxxxxxxxxxxxxxx
          Reporter: doug.knight@xxxxxxxxxx
  Target Milestone: ---

When using mod_systemd on a system with a systemd httpd service of type notify,
we have encountered a scenario where the command `systemctl reload httpd` never
returns.  In this case, systemd continues to report the service as reloading,
even though httpd respawned all of its server processes.

I have tracked the problem down to the way in which an `ExtendedStatus Off`
directive in the local configuration is interacting with the code introduced
here: http://svn.apache.org/viewvc?view=revision&revision=1802251 .  The
general sequence of events is:

1. User runs `systemctl reload httpd`.
2. systemd forks off an `httpd -k graceful` process, which exits successfully.
3. mod_systemd's systemd_pre_config hook sends a notification to systemd that
httpd is reloading, then sets ap_extended_status.
4. While reloading its configuration, httpd responds to an `ExtendedStatus Off`
directive by clearing ap_extended_status.
5. Subsequent calls to mod_systemd's systemd_monitor hook short-circuit when
they see that ap_extended_status is cleared so httpd stops sending status
updates to systemd.
6. systemd indefinitely reports httpd's state as reloading because it never
receives a READY=1 notification from mod_systemd's systemd_monitor hook.
7. The `systemctl reload httpd` command never exits.

I would expect httpd tell systemd when it finished reloading its configuration
regardless of the state of ap_extended_status.  I believe sending a
notification such as "READY=1\nSTATUS=ExtendedStatus is disabled." before
short-circuiting when ap_extended_status is cleared should resolve the issue,
but I haven't had an opportunity to setup a build environment to confirm.

You are receiving this mail because:
You are the assignee for the bug.
To unsubscribe, e-mail: bugs-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: bugs-help@xxxxxxxxxxxxxxxx