Replace SIGWINCH by SIGUSR2 in trunk?
Since APR-1.7 (r1854995), SIGUSR2 is removed from the list of
uncatchable synchronous signals so it could be used instead of
SIGWINCH for graceful stop in httpd.
The problem with SIGWINCH is when httpd is run from a pseudo-terminal
(not detached), it raises for any window resizing (which is not ideal,
notably when debugging).
The patch would look like the attached one. Not so bad idea?
Cheers;
Yann.
Index: include/mpm_common.h
===
--- include/mpm_common.h (revision 1889960)
+++ include/mpm_common.h (working copy)
@@ -45,6 +45,7 @@
#include /* for TCP_NODELAY */
#endif
+#include "apr_version.h"
#include "apr_proc_mutex.h"
#ifdef __cplusplus
@@ -73,13 +74,25 @@ extern "C" {
#define AP_SIG_GRACEFUL_STRING "SIGUSR1"
/* Signal used to gracefully stop */
+#if APR_VERSION_AT_LEAST(1,7,0)
+#define AP_SIG_GRACEFUL_STOP SIGUSR2
+#else
#define AP_SIG_GRACEFUL_STOP SIGWINCH
+#endif
/* Signal used to gracefully stop (without SIG prefix) */
+#if APR_VERSION_AT_LEAST(1,7,0)
+#define AP_SIG_GRACEFUL_STOP_SHORT USR2
+#else
#define AP_SIG_GRACEFUL_STOP_SHORT WINCH
+#endif
/* Signal used to gracefully stop (as a quoted string) */
+#if APR_VERSION_AT_LEAST(1,7,0)
+#define AP_SIG_GRACEFUL_STOP_STRING "SIGUSR2"
+#else
#define AP_SIG_GRACEFUL_STOP_STRING "SIGWINCH"
+#endif
/**
* Callback function used for ap_reclaim_child_processes() and
Index: server/mpm/motorz/motorz.c
===
--- server/mpm/motorz/motorz.c (revision 1889960)
+++ server/mpm/motorz/motorz.c (working copy)
@@ -855,7 +855,7 @@ static void child_main(motorz_core_t *mz, int chil
status = apr_pollset_add(mz->pollset, pfd);
if (status != APR_SUCCESS) {
-/* If the child processed a SIGWINCH before setting up the
+/* If the child processed a signal before setting up the
* pollset, this error path is expected and harmless,
* since the listener fd was already closed; so don't
* pollute the logs in that case. */
Index: server/mpm/netware/mpm_netware.c
===
--- server/mpm/netware/mpm_netware.c (revision 1889960)
+++ server/mpm/netware/mpm_netware.c (working copy)
@@ -121,7 +121,7 @@ static int mpm_state = AP_MPMQ_STARTING;
/*
* The max child slot ever assigned, preserved across restarts. Necessary
- * to deal with MaxRequestWorkers changes across SIGWINCH restarts. We use this
+ * to deal with MaxRequestWorkers changes across graceful restarts. We use this
* value to optimize routines that have to scan the entire scoreboard.
*/
static int ap_max_workers_limit = -1;
@@ -285,7 +285,7 @@ static void sig_term(int sig)
DBPRINT0 ("goodbye\n");
}
-/* restart() is the signal handler for SIGHUP and SIGWINCH
+/* restart() is the signal handler for SIGHUP and AP_SIG_GRACEFUL_STOP
* in the parent process, unless running in ONE_PROCESS mode
*/
static void restart(void)
Index: server/mpm/prefork/prefork.c
===
--- server/mpm/prefork/prefork.c (revision 1889960)
+++ server/mpm/prefork/prefork.c (working copy)
@@ -472,7 +472,7 @@ static void child_main(int child_num_arg, int chil
status = apr_pollset_add(pollset, pfd);
if (status != APR_SUCCESS) {
-/* If the child processed a SIGWINCH before setting up the
+/* If the child processed a signal before setting up the
* pollset, this error path is expected and harmless,
* since the listener fd was already closed; so don't
* pollute the logs in that case. */
Re: log config and variables
On Mon, May 17, 2021 at 8:47 AM Stefan Eissing wrote: > > With possibly multiple SSL modules active in our server, I am looking what to > do about the logging configuration. > > The current situation: mod_ssl registers log handler for tags "x" and "c". > Those do > - "x" does a lookup of the SSL_* variable name > - "c" does a shorthand translation of 6 variables names to the ones available > via "x". In addition it gives "-" as value for "errcode" and the client > verification error for "errstr". > > The problem is that there can only be one(!) handler registered for a tag. > > Now "x" can be easily done in mod_log_config itself now what we have > ap_ssl_var_lookup() in the core server. This means we can move that code from > mod_ssl to mod_log_config. +1 > To make the "c" handler work in core, we can also move the code from mod_ssl > to mod_log_config. But we need to define a variable name for the "errstr", > for example as "SSL_CLIENT_VERIFY_ERRSTR" which mod_ssl needs to supply then. If you mean ssl_var_lookup would handle "SSL_CLIENT_VERIFY_ERRSTR" +1
Re: log config and variables
On Mon, May 17, 2021 at 3:17 PM Eric Covener wrote: > > On Mon, May 17, 2021 at 8:47 AM Stefan Eissing > wrote: > > > > With possibly multiple SSL modules active in our server, I am looking what > > to do about the logging configuration. > > > > The current situation: mod_ssl registers log handler for tags "x" and "c". > > Those do > > - "x" does a lookup of the SSL_* variable name > > - "c" does a shorthand translation of 6 variables names to the ones > > available via "x". In addition it gives "-" as value for "errcode" and the > > client verification error for "errstr". > > > > The problem is that there can only be one(!) handler registered for a tag. > > > > Now "x" can be easily done in mod_log_config itself now what we have > > ap_ssl_var_lookup() in the core server. This means we can move that code > > from mod_ssl to mod_log_config. > > +1 +1 > > > To make the "c" handler work in core, we can also move the code from > > mod_ssl to mod_log_config. But we need to define a variable name for the > > "errstr", for example as "SSL_CLIENT_VERIFY_ERRSTR" which mod_ssl needs to > > supply then. > > If you mean ssl_var_lookup would handle "SSL_CLIENT_VERIFY_ERRSTR" +1 +1
Re: NOTICE: Intent to T on Sunday May 16, 2021
Done. > Am 17.05.2021 um 13:44 schrieb Stefan Eissing : > > Christophe, > > do I still have an hour to update the mod_md documentation? > > Cheers, Stefan > >> Am 17.05.2021 um 07:54 schrieb Marion & Christophe JAILLET >> : >> >> Hi all, >> >> the issues that have shown up just before the announcement of 2.4.48 seem to >> be gone now. >> >> So I'll T a new 2.4.48 for testing later today. >> >> CJ >> >> Le 03/05/2021 à 21:29, Christophe JAILLET a écrit : >>> Hi all, >>> as you probably have noticed, the 2.4.47 has been distributed on mirrors >>> but not announced, neither on your favorite ML, nor on the official >>> httpd.apache.org website. >>> The reason is a very last minute regression discovered a few hours before >>> the announcement. >>> So, as the 2.4.32 release in March 2018, this 2.4.47 release will never be >>> officially announced. >>> In the hope of this issue being solved in the meantime, I plan a new T on >>> Sunday May 16, 2021, forecasting for a 2.4.48 release on Sunday May 23 or >>> Monday May 24. >>> Best regards, >>> Christophe JAILLET >
Re: NOTICE: Intent to T on Sunday May 16, 2021
Christophe, do I still have an hour to update the mod_md documentation? Cheers, Stefan > Am 17.05.2021 um 07:54 schrieb Marion & Christophe JAILLET > : > > Hi all, > > the issues that have shown up just before the announcement of 2.4.48 seem to > be gone now. > > So I'll T a new 2.4.48 for testing later today. > > CJ > > Le 03/05/2021 à 21:29, Christophe JAILLET a écrit : >> Hi all, >> as you probably have noticed, the 2.4.47 has been distributed on mirrors but >> not announced, neither on your favorite ML, nor on the official >> httpd.apache.org website. >> The reason is a very last minute regression discovered a few hours before >> the announcement. >> So, as the 2.4.32 release in March 2018, this 2.4.47 release will never be >> officially announced. >> In the hope of this issue being solved in the meantime, I plan a new T on >> Sunday May 16, 2021, forecasting for a 2.4.48 release on Sunday May 23 or >> Monday May 24. >> Best regards, >> Christophe JAILLET
log config and variables
With possibly multiple SSL modules active in our server, I am looking what to do about the logging configuration. The current situation: mod_ssl registers log handler for tags "x" and "c". Those do - "x" does a lookup of the SSL_* variable name - "c" does a shorthand translation of 6 variables names to the ones available via "x". In addition it gives "-" as value for "errcode" and the client verification error for "errstr". The problem is that there can only be one(!) handler registered for a tag. Now "x" can be easily done in mod_log_config itself now what we have ap_ssl_var_lookup() in the core server. This means we can move that code from mod_ssl to mod_log_config. To make the "c" handler work in core, we can also move the code from mod_ssl to mod_log_config. But we need to define a variable name for the "errstr", for example as "SSL_CLIENT_VERIFY_ERRSTR" which mod_ssl needs to supply then. This change would be 100% backward compatible, I think, and allow other modules to supply their values as well. If this finds agreement, I will work on the changes in the coming days. Cheers, Stefan
Re: log config and variables
On 5/17/21 4:44 PM, Yann Ylavic wrote: > On Mon, May 17, 2021 at 3:17 PM Eric Covener wrote: >> >> On Mon, May 17, 2021 at 8:47 AM Stefan Eissing >> wrote: >>> >>> With possibly multiple SSL modules active in our server, I am looking what >>> to do about the logging configuration. >>> >>> The current situation: mod_ssl registers log handler for tags "x" and "c". >>> Those do >>> - "x" does a lookup of the SSL_* variable name >>> - "c" does a shorthand translation of 6 variables names to the ones >>> available via "x". In addition it gives "-" as value for "errcode" and the >>> client verification error for "errstr". >>> >>> The problem is that there can only be one(!) handler registered for a tag. >>> >>> Now "x" can be easily done in mod_log_config itself now what we have >>> ap_ssl_var_lookup() in the core server. This means we can move that code >>> from mod_ssl to mod_log_config. >> >> +1 > +1 > >> >>> To make the "c" handler work in core, we can also move the code from >>> mod_ssl to mod_log_config. But we need to define a variable name for the >>> "errstr", for example as "SSL_CLIENT_VERIFY_ERRSTR" which mod_ssl needs to >>> supply then. >> >> If you mean ssl_var_lookup would handle "SSL_CLIENT_VERIFY_ERRSTR" +1 > +1 > +1 to both above. Regards Rüdiger
[VOTE] Release httpd-2.4.48
Hi, all; Please find below the proposed release tarball and signatures: https://dist.apache.org/repos/dist/dev/httpd/ I would like to call a VOTE over the next few days to release this candidate tarball as 2.4.48: [ ] +1: It's not just good, it's good enough! [ ] +0: Let's have a talk. [ ] -1: There's trouble in paradise. Here's what's wrong. The computed digests of the tarball up for vote are: sha1: b581bcfdd939fe77c3821f7ad3863c7307374919 *httpd-2.4.48.tar.gz sha256: 315c0bc50206b866fb17c2cdc28c1973765a8d59ca168b80286e8cb077d0510e *httpd-2.4.48.tar.gz sha512: 91980f757fc0dede8c6cbf54ed973f82a63098aa50d0fce15fe3537687b4ffbb48ed50cdb4ae14eb4a8703450f032daf73f4f3d5e2dd0f75721948e12a9c6dfb *httpd-2.4.48.tar.gz The SVN tag is '2.4.48' at r1889975. -- Christophe JAILLET
Passed: apache/httpd#1633 (2.4.48 - c37a316)
Build Update for apache/httpd - Build: #1633 Status: Passed Duration: 14 mins and 43 secs Commit: c37a316 (2.4.48) Author: Christophe Jaillet Message: Tag HEAD of 2.4.x as 2.4.48 git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/tags/2.4.48@1889975 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/httpd/commit/c37a3162d1c0 View the full build log and details: https://travis-ci.com/github/apache/httpd/builds/226145134?utm_medium=notification_source=email -- You can unsubscribe from build emails from the apache/httpd repository going to https://travis-ci.com/account/preferences/unsubscribe?repository=16806660_medium=notification_source=email. Or unsubscribe from *all* email updating your settings at https://travis-ci.com/account/preferences/unsubscribe?utm_medium=notification_source=email. Or configure specific recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications.
Re: [VOTE] Release httpd-2.4.48
Christophe JAILLET in gmane.comp.apache.devel (Mon, 17 May 2021 23:36:29 +0200): >https://dist.apache.org/repos/dist/dev/httpd/ > >I would like to call a VOTE over the next few days to release this >candidate tarball as 2.4.48: >[x] +1: It's not just good, it's good enough! I tested the substantial changes in mod_md with - Windows VC9 x86 - Windows VC15 x64 New certificates were generated as expected. -- Jan
