Re: [PATCH] Fix settings options with ProxyPassMatch
This is also needed to fix ProxyPassMatch with UDS. Without this patch following configuration does not work: ProxyPassMatch ^/web/(.*\.php)$ unix:/run/php-fpm/fpm.sock|fcgi://127.0.0.1/var/www/html/$1 If nobody is against, I will commit it to trunk later this week. Regards, Jan Kaluza On 09/16/2013 02:44 PM, Jan Kaluža wrote: Hi, I have found out that if you use ProxyPassMatch with regexp and $1 (see PR 43513 and PR 54973), the right proxy_worker is not used and reverse proxy_worker is used instead. The result is situation where no options like timeout can be set in this case. The real problem here is that proxy_worker is chosen according to its name which contains $1 sequence in our case. I have found out that there is already patch fixing ProxyPassMatch behaviour with $1 in PR 43513. I have rebased the patch for trunk and changed its style a bit. The patch strips everything after $, so it for example changes the name of proxy_worker from http://127.0.0.1/cgi-bin/$1; to http://127.0.0.1/cgi-bin/;. Later when request arrives, proper proxy_worker is chosen. Without this change, proxy_worker's name with $1 would be compared against real request URL, but real request URL does not contain this $1 sequence and therefore this correct proxy_worker wouldn't be chosen. Do you see any problems with this patch? Regards, Jan Kaluza
Re: [PATCH] Fix settings options with ProxyPassMatch
On 03/18/2014 02:46 PM, Yann Ylavic wrote: On Tue, Mar 18, 2014 at 2:38 PM, Yann Ylavic ylavic@gmail.com wrote: Wouldn't it be possible to define wildcard workers when the URL is known to be a regexp substitution? For these workers' URLs, the dollars (plus the following digit) could be replaced by a wildcard (ie. *) and ap_proxy_get_worker() could then use ap_strcasecmp_match() against the requested URL. I meant ap_strcmp_match(), this has to be case sensitive... That looks like good way too. I will give it a try. Maybe it will look better than this original patch (with which I'm not so sure...) Regards, Jan Kaluza
Re: svn commit: r1550060 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_config.c
On 12/13/2013 09:54 AM, Ruediger Pluem wrote:
jkal...@apache.org wrote:
Author: jkaluza
Date: Wed Dec 11 07:16:28 2013
New Revision: 1550060
URL: http://svn.apache.org/r1550060
Log:
mod_ssl: Add -t -DDUMP_CA_CERTS option which dumps the filenames of all
configured SSL CA certificates to stdout the same way as DUMP_CERTS does.
Modified:
httpd/httpd/trunk/CHANGES
httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
Modified: httpd/httpd/trunk/modules/ssl/ssl_engine_config.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_config.c?rev=1550060r1=1550059r2=1550060view=diff
==
--- httpd/httpd/trunk/modules/ssl/ssl_engine_config.c (original)
+++ httpd/httpd/trunk/modules/ssl/ssl_engine_config.c Wed Dec 11 07:16:28 2013
@@ -1870,30 +1870,95 @@ const char *ssl_cmd_SSLSRPUnknownUserSee
#endif /* HAVE_SRP */
-void ssl_hook_ConfigTest(apr_pool_t *pconf, server_rec *s)
+static void dump_ca_cert_file(apr_file_t *out, const char *file) {
+X509 *rc;
+BIO *bioS;
+
+if ((bioS=BIO_new_file(file, r)) == NULL) {
+return;
+}
+
+/* ca_cert_file is loaded using SSL_load_client_CA_file(). This method
+ * loads only file of PEM formatted certificates, so we have to load
+ * only PEM here too, to stay consistent.
+ */
+rc = PEM_read_bio_X509 (bioS, NULL, NULL, NULL);
+BIO_free(bioS);
+if (rc) {
+apr_file_printf(out, %s\n, file);
Hm, do I miss the point or why don't we print out anything from the cert we
just loaded and just the filename?
Do we just want to know if the cert file loads?
At first sorry for late response, I was away during Christmas time. The
idea was to stay consistent with what DUMP_CERTS does, so DUMP_CA_CERTS
prints only filename of the cert so it can be later passed to certwatch.
I'm trying to load the certificate to find out if it's valid. I think
this has to be done, because you can use SSLCACertificatePath to set
path to directory containing CA certificates and to print really only
valid certificates from this directory, we have to actually try to load
them and ignore those which can't be loaded.
This is not done for DUMP_CERTS, because there is no directory
equivalent of SSLCertificateFile (which is logical).
If we presume that directory specified by SSLCACertificatePath contains
only valid certificates and no other files, we could remove that
validity check and just print filenames of all files in that directory.
Regards
Rüdiger
Regards,
Jan Kaluza
Re: svn commit: r1550060 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_config.c
On 12/22/2013 09:30 AM, Kaspar Brand wrote: On 11.12.2013 08:16, jkal...@apache.org wrote: Author: jkaluza Date: Wed Dec 11 07:16:28 2013 New Revision: 1550060 URL: http://svn.apache.org/r1550060 Log: mod_ssl: Add -t -DDUMP_CA_CERTS option which dumps the filenames of all configured SSL CA certificates to stdout the same way as DUMP_CERTS does. In addition to what Rüdiger noted (on 13 December): are -DDUMP_CERTS and -DDUMP_CA_CERTS supposed to be mutually exclusive? Right now, specifying both will have the effect of only outputting the certs (due to the early return in line 1937). They were intended to be mutually exclusive, but I admit the current situation is not optimal. I should have checked for this and do something smarter than outputting only certs... Another idea is to interleave server and CA cert information and output them by the vhost_id, e.g.: foo.example.net:443 Server: /usr/local/apache2/conf/server-foo.crt CA: /usr/local/apache2/conf/ssl.crt/ca-bundle-foo.crt bar.example.net:443 Server: /usr/local/apache2/conf/server-bar.crt CA: /usr/local/apache2/conf/ssl.crt/ca-bundle-bar.crt ... Hm, I'm not sure we can change the output format without breaking tools like certwatch and outputting in this format only when both options are set would need more complex code. But if people here think we could change output format of DUMP_CERTS according to example above, I can create this patch. And third, could we document -DDUMP_CERTS and -DDUMP_CA_CERTS on this occasion (either in server/main.c or docs/man/httpd.8)? I will do that. Kaspar Regards, Jan Kaluza
Re: error log providers, multiple vhosts, mod_syslog
On 11/07/2013 07:07 PM, Jeff Trawick wrote: On Thu, Nov 7, 2013 at 7:09 AM, Jan Kaluža jkal...@redhat.com mailto:jkal...@redhat.com wrote: On 11/07/2013 11:11 AM, Joe Orton wrote: On Thu, Oct 17, 2013 at 12:33:50PM +, Plüm, Rüdiger, Vodafone Group wrote: Hmm. This points out another issue when using an error log provider for the main server log: We lose everything that the server or other programs like CGI-scripts write to the stderr FD as it is simply written to /dev/null. Don't we need to have a separate process in this case that like a piped logger reads from the reading end of the stderr pipe and writes it via ap_server_conf-errorlog___provider-writer to the log? Jumping in here... Actually there should be few cases where modules write to stderr, no? I'm not sure we should even consider writes to stderr get logged a valid part of the module API. If you're not using ap_log_*error, you're out of luck is not totally unreasonable. mod_cgi does intercept stderr and logs it properly via ap_log_rerror, and mod_cgid does stderr logging differently anyway. One case which is common is the use of apr_procattr_child_errfn_set() to write exec() errors to stderr after forking a child. But perhaps we could and should provide a single common implementation of that which does something more useful. With ErrorLog syslog in current 2.x (and 1.3?), stderr is /dev/null already, so the status quo is that we lose stuff, though that is kind of ugly. Reading this I think I could commit my httpd-trunk-stderr-provider.__patch from older email in this thread. It does not fix stderr logging, but it fixes httpd-trunk problem where messages with NULL server_rec* are not logged. I'm attaching better version of that patch here (it fixes potential crash pointed out by Rüdiger when both logf and error_log_provider are NULL). If anyone is against it or has better idea how to fix logging of messages with NULL server_rec* when log providers are used, tell me. Is the observation about NULL server_rec for modules that weren't updated properly to pass ap_server_conf when no server_rec was available, or for some window where ap_server_conf is NULL but server_rec is needed? I've originally observed that right in log.c in open_error_log(). ap_log_error calls there have NULL server_rec and in case something goes wrong during vhost logger initialization, the error messages about that are lost in case you use error log provider in ap_server_conf. That's what I'm trying to fix by that patch. I haven't checked if there are other places where NULL server_rec is used, but I would say it's pretty common during httpd startup. Jan Kaluza Regards, Joe Regards, Jan Kaluza -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: error log providers, multiple vhosts, mod_syslog
On 10/15/2013 05:27 PM, Jeff Trawick wrote:
Does this patch/commit look okay? It works for me with a simple
provider in different scenarios (vhost that inherits provider setup from
s_main, vhost that has its own setup).
The patch looks OK to me. Thanks for it.
I suppose mod_syslog needs to disallow any attempts to configure it in a
vhost with different settings since openlog() is process-wide. Jan, can
you look at that by chance?
Yes, I will do this later today.
Regards,
Jan Kaluza
-- Forwarded message --
From: ** traw...@apache.org mailto:traw...@apache.org
Date: Tue, Oct 15, 2013 at 10:09 AM
Subject: svn commit: r1532344 - /httpd/httpd/trunk/server/log.c
To: c...@httpd.apache.org mailto:c...@httpd.apache.org
Author: trawick
Date: Tue Oct 15 14:09:29 2013
New Revision: 1532344
URL: http://svn.apache.org/r1532344
Log:
Follow-up to r1525597:
Initialize error log providers in vhosts, solving crashes
when logging from those vhosts as well as allowing a different
provider (or provider configuration) for vhosts.
Modified:
httpd/httpd/trunk/server/log.c
Modified: httpd/httpd/trunk/server/log.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/log.c?rev=1532344r1=1532343r2=1532344view=diff
==
--- httpd/httpd/trunk/server/log.c (original)
+++ httpd/httpd/trunk/server/log.c Tue Oct 15 14:09:29 2013
@@ -458,6 +458,18 @@ int ap_open_logs(apr_pool_t *pconf, apr_
virt-error_log = q-error_log;
}
}
+else if (virt-errorlog_provider) {
+/* separately-configured vhost-specific provider */
+if (open_error_log(virt, 0, p) != OK) {
+return DONE;
+}
+}
+else if (s_main-errorlog_provider) {
+/* inherit provider from s_main */
+virt-errorlog_provider = s_main-errorlog_provider;
+virt-errorlog_provider_handle =
s_main-errorlog_provider_handle;
+virt-error_log = NULL;
+}
else {
virt-error_log = s_main-error_log;
}
--
Born in Roswell... married an alien...
http://emptyhammock.com/
[PATCH] svn commit: r377292 - Clean up some code in mod_dav.
Hi,
while trying to fix bug #55426 I have found out that commit
http://svn.apache.org/r377292 is probably wrong. If my analysis is correct,
the first ap_get_status_line(...) call has to remain in the code, because
r-status_line is used right in the next call of ap_rvputs(...) and currently
this r-status_line is reflecting old status or is null.
It's true that r-status_line can be set by basic_http_header_check(...) later,
but in the case of dav_error_response we need r-status_line to be set earlier
to be able to call ap_rvputs(...).
Attached patch reverts the first part of r377292 and also fixes bug #55426 for
me.
Regards,
Jan Kaluza
Index: modules/dav/main/mod_dav.c
===
--- modules/dav/main/mod_dav.c (revision 1520983)
+++ modules/dav/main/mod_dav.c (working copy)
@@ -315,6 +315,7 @@
static int dav_error_response(request_rec *r, int status, const char *body)
{
r-status = status;
+r-status_line = ap_get_status_line(status);
ap_set_content_type(r, text/html; charset=ISO-8859-1);
Re: [PATCH] Make error logging modular
- Original Message - Hello Jan, Is there any reason we shouldn't do this in trunk? I don't see any reason. This patch was intended for trunk, but I don't have svn commit access, so I'm sending patches to this list :). It's also better that someone reviews my code, because I don't have so long experience with httpd development. Regards, Jan Kaluza The patches and features seem generally correct to me with a cursory review. Thanks, Paul On Mon, May 27, 2013 at 3:23 AM, Jan Kaluža jkal...@redhat.com wrote: Hi, last week I was trying to write my own module to log error_log to systemd-journal [1] and I've found out that with the current error_log code, it's not possible to do that properly. I was able to use error_log hook, but there is no way to disable creation of ErrorLog file (One can set it to /dev/null, but httpd will still write data to it without any reason). Syslog logger fixes that by hardcoding syslog methods in log.c/core.c, but I don't think that's the right thing to do with journald. Therefore, I've created following patches: http://people.apache.org/~jkaluza/patches/logging/ Their descriptions should be clear from their names, but I will describe them briefly here too. Patch 0001 declares ap_errorlog_provider which can be implemented by module providing error_log logger. Admin can later define ErrorLog provider arg to choose particular errorlog provider. Old syntax still works and the change is backward compatible. This patch also removes syslog logging from log.c (it is moved to newly created mod_syslog.c in next patch) Patch 0002 creates mod_syslog.c which uses the new API to implement syslog logging. It works the same way as the version in log.c I removed in previous patch, but it's in separate module. Patch 0003 shows how mod_journald.c can use the existing API. This module works well with systemd-journal, but unfortunately the performance of systemd-journal daemon is poor so far [2], but I presume it will be fixed and the module will be usable for general use in the future. There is probably no real benefit in accepting this last patch right now. It's here to only show why the previous two patches are useful. Note that this is my first bigger patch touching httpd core, so feel free to correct my possible mistakes... :) [1] http://0pointer.de/blog/projects/journalctl.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=963620 [patches] http://people.apache.org/~jkaluza/patches/logging/ Regards, Jan Kaluza
Re: [PATCH] Fix LDAPReferrals off
- Original Message - On Thu, Jun 20, 2013 at 8:49 AM, Jan Kaluža jkal...@redhat.com wrote: On 06/20/2013 02:41 PM, Eric Covener wrote: On Thu, Jun 20, 2013 at 8:33 AM, Jan Kaluža jkal...@redhat.com wrote: On 06/20/2013 02:25 PM, Eric Covener wrote: Do you think we should tolerate an error turning referrals off? That's good point. I'm not ldap expert, but I would say we should not tolerate that. Admin has to explicitly disable referrals and if he does that, he probably has some reason why to do it. But if someone more experienced thinks we should tolerate that error, I'm not against. I'm only concerned with someone who was getting by with LDAPReferrals OFF because the default gave their SDK an error. Now OFF would be fatal too. But it's not so easy to do a separate default option because other parts of the code need to know if referrals are being chased. In this case I think we could change the patch to not call ldap_set_option for referrals at all unless the admin specifies the value in config file. I mean to define AP_LDAP_CHASEREFERRALS_UNSET and if the ldc-chaseReferrals == AP_LDAP_CHASEREFERRALS_UNSET, then do nothing. I can submit patch like that tomorrow. This should be good for everyone, right? I don't know what that means for other and/or older LDAP SDKs, so I would rather not flip that. Hm, I think the only way how to get out of this without taking a risk of breaking the current behaviour is to allow setting something like LDAPReferrals default (probably not good name, but I'm not sure I can come up with better one right now). By default, LDAPReferrals would still be set to on. If you would like to not set referrals option, you would use the default value. off value would try to turn the referrals off. Of course it would be better to patch apr_ldap_option.c for SDKs where referrals option can't be set, but I don't have the knowledge to do that. Regards, Jan Kaluza
Re: Apache 2.4 adoption
- Original Message - On 07/02/2013 09:47, Jan Kaluža wrote: [snip] The problem is that I have little experience with Perl or mod_perl. I'm trying to improve current situation, but I don't want to be the upstream, because I'm not active mod_perl (or even Perl) user. [snip] Maybe there is someone here who loves that project so much that he could actually help maintaining it? Regards, Jan Kaluza If I make it to AC (still unsure, unfortunately) and have some time at the hackathon (also iffy), I'd be happy to lend a pair of hands and/or eyes to help review your changes. Will you be there? I'm afraid I won't be there :(, but I will try to upload and clean all my patches before that, so if you guys will manage to do something with mod_perl, you can base it on my work. I can also be online on IRC during the hackathon. Though I've done XS development, a bit of mod_perl stuff in the past and httpd, I don't have time to turn that into a long-term commitment. It would be awesome to have someone who understands XS to comment my patches, because I'm basically learning it on mod_perl and even when it works, I'm not sure I've done the best decisions or the best way how to do things. I'm more than happy to contribute to mod_perl, but not to maintain itt (at least not for now). Issac Jan Kaluza
mod_cache logging when CacheRoot does not exist
Hi,
if you use CacheRoot which does not exist or where httpd does not have
permissions to write, then the caching does not work and there is no
error message in log in this case.
This makes detection of this situation and further debugging harder,
because to find out what's going on, you have to set LogLevel to debug.
I think mod_cache should log message 00765 with ERR log level instead of
DEBUG (attached patch does that) or new mod_cache_disk log message should
be added to address this particular error.
Regards,
Jan Kaluza
Index: modules/cache/mod_cache.c
===
--- modules/cache/mod_cache.c (revision 1439320)
+++ modules/cache/mod_cache.c (working copy)
@@ -656,7 +656,7 @@
rv = cache-provider-store_body(cache-handle, f-r, in, cache-out);
if (rv != APR_SUCCESS) {
-ap_log_rerror(APLOG_MARK, APLOG_DEBUG, rv, f-r, APLOGNO(00765)
+ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, f-r, APLOGNO(00765)
cache: Cache provider's store_body failed!);
ap_remove_output_filter(f);
[PATCH] More useful data in ap_sload_t
Hi,
attached patch adds more variables (bytes_served and access_count) into
ap_sload_t struct introduced in revision 1389481.
The intention is to have standard method to get number of total bytes_served
and access_count without code duplication.
Thanks for reviewing,
Jan Kaluza
Index: server/util.c
===
--- server/util.c (revision 1389886)
+++ server/util.c (working copy)
@@ -2802,6 +2802,8 @@
/* preload errored fields, we overwrite */
ld-idle = -1;
ld-busy = -1;
+ld-bytes_served = 0;
+ld-access_count = 0;
ap_mpm_query(AP_MPMQ_GENERATION, mpm_generation);
ap_mpm_query(AP_MPMQ_HARD_LIMIT_THREADS, thread_limit);
@@ -2825,6 +2827,14 @@
ps-generation == mpm_generation) {
busy++;
}
+
+if (ap_extended_status !ps-quiescing ps-pid) {
+if (ws-access_count != 0 ||
+(res != SERVER_READY res != SERVER_DEAD)) {
+ld-access_count += ws-access_count;
+ld-bytes_served += ws-bytes_served;
+}
+}
}
}
total = busy + ready;
Index: include/httpd.h
===
--- include/httpd.h (revision 1389886)
+++ include/httpd.h (working copy)
@@ -1308,6 +1308,10 @@
int idle;
/* percentage of process/threads busy (0-100) */
int busy;
+/* total bytes served */
+apr_off_t bytes_served;
+/* total access count */
+unsigned long access_count;
};
/**
[PATCH] mod_systemd
Hi,
attached patch adds new module called mod_systemd. Systemd [1] is service
manager for Linux. Although httpd works with systemd normally, systemd provides
sd_notify(...) function [2] to inform service manager about current status of
the service. Status message passed to service manager using this function is
later visible in systemctl status httpd.service output and can provide useful
information about current httpd status.
The goal of this module is to update httpd's status message regularly to
provide information like number of idle/busy workers, total requests or for
example number of requests per second. It uses data from the ap_get_sload(...)
function and depends on my httpd-sload.patch from previous mail.
I've tried to choose some interesting data for the status message, but if you
think admins would like to see something different there, I'm open to
suggestions. Note that it has to be single line of text, so there's no space
for lot of data.
[1] http://www.freedesktop.org/wiki/Software/systemd
[2] http://www.freedesktop.org/software/systemd/man/sd_notify.html
Thanks for reviewing,
Jan Kaluza
Index: modules/arch/unix/config5.m4
===
--- modules/arch/unix/config5.m4 (revision 1389886)
+++ modules/arch/unix/config5.m4 (working copy)
@@ -19,6 +19,19 @@
fi
])
+
+APACHE_MODULE(systemd, Systemd support, , , $unixd_mods_enabled, [
+ AC_CHECK_LIB(systemd-daemon, sd_notify, SYSTEMD_LIBS=-lsystemd-daemon)
+ AC_CHECK_HEADERS(systemd/sd-daemon.h, [ap_HAVE_SD_DAEMON_H=yes], [ap_HAVE_SD_DAEMON_H=no])
+ if test $ap_HAVE_SD_DAEMON_H = no || test -z ${SYSTEMD_LIBS}; then
+AC_MSG_WARN([Your system does not support systemd.])
+enable_systemd=no
+ else
+APR_ADDTO(MOD_SYSTEMD_LDADD, [$SYSTEMD_LIBS])
+enable_systemd=yes
+ fi
+])
+
APR_ADDTO(INCLUDES, [-I\$(top_srcdir)/$modpath_current])
APACHE_MODPATH_FINISH
Index: modules/arch/unix/mod_systemd.c
===
--- modules/arch/unix/mod_systemd.c (revision 0)
+++ modules/arch/unix/mod_systemd.c (working copy)
@@ -0,0 +1,103 @@
+/* Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the License); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an AS IS BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ */
+
+#include stdint.h
+#include ap_config.h
+#include ap_mpm.h
+#include http_core.h
+#include httpd.h
+#include http_log.h
+#include apr_version.h
+#include apr_pools.h
+#include apr_strings.h
+#include unixd.h
+#include scoreboard.h
+#include mpm_common.h
+
+#include systemd/sd-daemon.h
+
+#if APR_HAVE_UNISTD_H
+#include unistd.h
+#endif
+
+static int systemd_pre_mpm(apr_pool_t *p, ap_scoreboard_e sb_type)
+{
+int rv;
+pid_t pid;
+pid = getpid();
+
+ap_extended_status = 1;
+
+rv = sd_notifyf(0, READY=1\n
+STATUS=Processing requests...\n
+MAINPID=%lu,
+(unsigned long) pid);
+if (rv 0) {
+ap_log_perror(APLOG_MARK, APLOG_ERR, 0, p, APLOGNO(0)
+ sd_notifyf returned an error %d, rv);
+}
+
+return OK;
+}
+
+static int systemd_monitor(apr_pool_t *p, server_rec *s)
+{
+ap_sload_t sload;
+apr_interval_time_t up_time;
+char bps[5];
+int rv;
+
+ap_get_sload(sload);
+/* up_time in seconds */
+up_time = (apr_uint32_t) apr_time_sec(apr_time_now() -
+ ap_scoreboard_image-global-restart_time);
+
+apr_strfsize((unsigned long)((float) (sload.bytes_served)
+ / (float) up_time), bps);
+
+rv = sd_notifyf(0, READY=1\n
+STATUS=Total requests: %lu; Idle/Busy workers %d/%d;
+Requests/sec: %.3g; Bytes served/sec: %sB/sec\n,
+sload.access_count, sload.idle, sload.busy,
+((float) sload.access_count) / (float) up_time, bps);
+
+if (rv 0) {
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO(1)
+ sd_notifyf returned an error %d, rv);
+}
+
+return DECLINED;
+}
+
+static void systemd_register_hooks(apr_pool_t *p)
+{
+/* We know the PID in this hook ... */
+ap_hook_pre_mpm(systemd_pre_mpm, NULL, NULL, APR_HOOK_LAST);
+/* Used to update httpd's status line using
