On SIGWINCH usage, switch to SIGUSR2 nowadays?

[Yann Ylavic <yl...@gmail.com>]

Hi,

as you probably know, SIGWINCH is used both by terminal (emulators)
for window changes/redraw, and httpd for graceful stop (hardcoded
AFAICT).

This can cause issues when httpd is run in foreground from a terminal,
and as such (I think) is ignored in -X/ONE_PROCESS mode otherwise
gdb-ing would become quite irritating.

I'd like to be able to debug/instrument graceful stop with -X /
ONE_PROCESS though, without fearing to resize my gdb terminal or
something like that.

I suppose SIGUSR2 was not used some times ago because of its internal
usage in LinuxThreads (replaced by NPTL more than 10 years ago now),
or is/was there other systems/libcs which use SIGUSR2 for their own
purpose?

So, unless somewhere SIGUSR2 is still not a USeR available signal
nowadays, I propose that we switch to SIGUSR2, WDYT?
(There may be some tooling that uses SIGWINCH directly instead of "-k
graceful-stop", should be care?)

Could be something like the attached patch to "./configure -D
AP_SIG_GRACEFUL_STOP_SHORT=USR2 ...", or an hardcoded switch like
today...

Regards,
Yann.

Re: On SIGWINCH usage, switch to SIGUSR2 nowadays?

[Yann Ylavic <yl...@gmail.com>]

On Thu, Feb 21, 2019 at 5:31 PM Yann Ylavic <yl...@gmail.com> wrote:
>
> May I commit this (before unblocking graceful stop in ONE_PROCESS mode)?

OK, it requires an APR change anyway because SIGUSR2 is blocked by
apr_signal_thread().
I opened a thread there, wait and see, in any case it now depends on a
minimal APR version so things get complicated..

>
> Thanks,
> Yann.

Re: On SIGWINCH usage, switch to SIGUSR2 nowadays?

[Yann Ylavic <yl...@gmail.com>]

After some bit of research, I couldn't find a platform (besides Linux
< 2.6) where SIGUSR2 is "reserved", so possibly something like the
attached patch would be acceptable.

The patch adds --enable-graceful-stop-sigusr2 to configure(.in) which
default to "yes" (for trunk, but would default to "no" for a potential
backport to 2.4.x), and which anyway is forced to "no" for platforms
we know it won't work (linux < 2.6 for now, please add yours...).

May I commit this (before unblocking graceful stop in ONE_PROCESS mode)?

Thanks,
Yann.