Re: [users@httpd] graceful-stop closes established connections without response
On 1/31/24 3:11 PM, Sherrard Burton wrote: two is about par for the course _when there are resets_. but it doesn't necessarily happen on every test run. for example, after initially applying the v1 patch (and having fully composed a response to say that the patch seemed to have worked :-)), i discovered that i had forgotten to switch back from prefork to event. ie, i ran the test a few times in a row with no resets, even though the patch was not in play. i have not previously, but i will try to gather some statistics about number of resets per failed run and failed vs successful runs, since the combination of the two is needed to make any quantitative assessment. correction: two is par for the course when the client connection is remote. in order to have an iterable test setup, i created a bash loop that started the tcpdump, strace and curl instances all on the server while simultaneously gracefully stopping apache. with client connection coming from the localhost, we end up with many more reset connections per run, and failures present in each test. but ultimately, the results are such that i don't think any changes are warranted. stock debian apache 2.4.57-2, 100 iterations: average number of established connections/submitted requests: 67284 / 100 = 672.84 average number of responses received: 65162 / 100 = 651.62 average number of reset connections: 2122 / 100 = 21.22 patched with v3, 100 iterations: average number of established connections/submitted requests: 68319 / 100 = 683.19 average number of responses received: 66082 / 100 = 660.82 average number of reset connections: 2237 / 100 = 22.37 not sure if the slight increase in connections established and handled under the patched version indicates that there might be some benefit to the patch, or if the difference is small enough that it can be chalked up slight differences in resource demands in the VM host at the time that the tests were running. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] graceful-stop closes established connections without response
On 1/31/24 06:24 AM, Yann Ylavic wrote: On Tue, Jan 30, 2024 at 8:24 PM Sherrard Burton wrote: i have confirmed that the patch has been applied, and the behavior still persists, as confirmed by comparing the counts of [SYN,ACK] and accept() ~$ tcpdump -n -r /tmp/tcpdump.pcap | grep -Fc '[S.]'; grep -Fh 'accept4' /tmp/strace-apache2.out.* | grep -Fc .240.209 reading from file /tmp/tcpdump.pcap, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 Warning: interface names might be incorrect 3485 3483 This means those two connections came in (or were made available by the system) after the last accept() call, which is the race condition that httpd can do nothing about unfortunately. How much does it improve compared to non-patched httpd, how many reset connections without the patch? If not significant I don't think it's worth attempting to do something about it.. two is about par for the course _when there are resets_. but it doesn't necessarily happen on every test run. for example, after initially applying the v1 patch (and having fully composed a response to say that the patch seemed to have worked :-)), i discovered that i had forgotten to switch back from prefork to event. ie, i ran the test a few times in a row with no resets, even though the patch was not in play. i have not previously, but i will try to gather some statistics about number of resets per failed run and failed vs successful runs, since the combination of the two is needed to make any quantitative assessment. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] missing image
On Wed, Jan 31, 2024 at 2:54 PM Sherrard Burton wrote: > > > On 1/31/24 02:26 PM, Adam Weremczuk wrote: > > > > I've already tried replacing relative path to the image with absolute > > but it made no difference. > > > > Any ideas? > > > > do you have a live example with the absolute path? the broken ones that > i looked at all had the relative paths which (understandably) doesn't work. > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > > This sounds more like an html/content issue, unless httpd is mangling the request via mod_rewrite or another directive. In any case, if you get 404 responses, increase the log level and check the error log first.
Re: [users@httpd] missing image
On 1/31/24 02:26 PM, Adam Weremczuk wrote: I've already tried replacing relative path to the image with absolute but it made no difference. Any ideas? do you have a live example with the absolute path? the broken ones that i looked at all had the relative paths which (understandably) doesn't work. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
[users@httpd] missing image
Hi all, Apache 2.4.56. I'm trying to set up a holding page that would catch all traffic (including errors) and redirect to a very basic holding page. It seems to be working now as I want. Apart from the logo image missing if I supply any multi level path, e.g: 1. Logo showing: https://holding.matrixscience.com/invalid.php https://holding.matrixscience.com/invalid 2. Logo missing: https://holding.matrixscience.com/invalid/ https://holding.matrixscience.com/invalid/invalid.php https://holding.matrixscience.com/invalid1/invalid2/invalid.html I've already tried replacing relative path to the image with absolute but it made no difference. Any ideas? Thanks, Adam - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
[users@httpd] mod_fcgid problem in chroot: (38)Function not implemented
Dear all, Wishing you a good day. My day could have been better, I've been battling a problem with mod_fcgid in combination with ModSecurity's SecChrootDir feature, which chroots the webserver into /chroot/apache. The virtualhosts live under this and it's a nice feature. As soon as I enable mod_fcgid, Apache fails to start with the following error message: [fcgid:emerg] [pid 5344] (38)Function not implemented: mod_fcgid: Can't create shared memory for size 1200712 bytes My OS is Ubuntu 20.04 LTS. I've tried: * ensuring /chroot/apache/var/run/fcgid_shm and fcgidsock exist with mode 1777 * creating /chroot/apache/dev/shm with mode 1777 * using 'strace apache2ctl start' to see what syscall is being attempted, and hacking the apachectl script to start Apache directly even in the presence of $need_systemd so that it runs Apache directly - still I don't get any useful information from this * The error disappears whenever I disable the chroot functionality, but for security reasons I'd really like to keep the chroot enabled. Can anyone give me a hint to further debug this problem? Kind regards, Robbie
Re: [users@httpd] graceful-stop closes established connections without response
On Tue, Jan 30, 2024 at 8:24 PM Sherrard Burton wrote: > > i have confirmed that the patch has been applied, and the behavior still > persists, as confirmed by comparing the counts of [SYN,ACK] and accept() > > ~$ tcpdump -n -r /tmp/tcpdump.pcap | grep -Fc '[S.]'; grep -Fh 'accept4' > /tmp/strace-apache2.out.* | grep -Fc .240.209 > reading from file /tmp/tcpdump.pcap, link-type LINUX_SLL2 (Linux cooked > v2), snapshot length 262144 > Warning: interface names might be incorrect > 3485 > 3483 This means those two connections came in (or were made available by the system) after the last accept() call, which is the race condition that httpd can do nothing about unfortunately. How much does it improve compared to non-patched httpd, how many reset connections without the patch? If not significant I don't think it's worth attempting to do something about it.. Regards; Yann. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
