https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
Yann Ylavic changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #43 from Bernhard Friedreich ---
Thank you for the support and the lightning fast fix!
Thanks also to Michael for taking the time to debug the issue further :)
Looking forward to 2.4.44.
--
You are receiving this mail because:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
Yann Ylavic changed:
What|Removed |Added
Keywords||FixedInTrunk
--- Comment #42 from Yann
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #41 from Michael Haas ---
Thanks Yann, no leftover tmp files anymore.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe,
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
Yann Ylavic changed:
What|Removed |Added
Attachment #37282|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
Yann Ylavic changed:
What|Removed |Added
Attachment #37281|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #38 from Yann Ylavic ---
Created attachment 37281
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37281=edit
Preserve EOS in spool_reqbody_cl()
Could you please try this patch?
Actually the fix belongs in apr_file_mktemp
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #37 from Yann Ylavic ---
Thanks. Something dropped apr_unix_file_cleanup from the list in between
apr_file_mktemp and eor_bucket_destroy, without running it.
I think that the file is set aside when being forwarded to the backend
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #36 from Michael Haas ---
Created attachment 37280
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37280=edit
gdb dump-pool
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #35 from Yann Ylavic ---
If you downloaded the script already, please redo because there was a bug in
dump_pool_and_children which I just fixed.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #34 from Yann Ylavic ---
OK, how strange :/
Please copy this gdb init file
(https://svn.apache.org/viewvc/httpd/httpd/trunk/.gdbinit?view=co) to your
$HOME directory (i.e. "/root" if you run gdb as root), such that gdb loads
httpd
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #33 from Michael Haas ---
Created attachment 37277
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37277=edit
gdb eor_bucket_destroy
no breakpoint after first backtrace
--
You are receiving this mail because:
You are the
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #32 from Yann Ylavic ---
(In reply to Yann Ylavic from comment #31)
> And once in eor_bucket_destroy is reached (if ever), please do:
> (gdb) backtrace
> and then "next" until the end of the function
In eor_bucket_destroy there is
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #31 from Yann Ylavic ---
(In reply to Michael Haas from comment #30)
> made the trace, hopefully i got the commands in the proper order.
Yes, thanks a lot. You just missed to "step" in the second call to:
return
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #30 from Michael Haas ---
Created attachment 37274
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37274=edit
gdb trace
made the trace, hopefully i got the commands in the proper order.
I also can't recreate the problem
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #29 from Yann Ylavic ---
(In reply to Yann Ylavic from comment #28)
>
> Once the ap_process_request_after_handler breakpoint is hit, please "step"
> in the ap_pass_brigade call there,
Actually, once in
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #28 from Yann Ylavic ---
(In reply to Michael Haas from comment #21)
> => 2.4.43
> [...]
> Breakpoint 2, apr_file_mktemp (fp=0x7fffaa783828, template=0x7fffa40363e0
> "/tmp/modproxy.tmp.XX", flags=0, p=0x7fffa401f898) at
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #27 from Yann Ylavic ---
Thanks Michael, unfortunately there are multiple threads being scheduled in
your gdb trace, like here:
>504 apr_bucket_read(e, , _read, APR_BLOCK_READ);
>(gdb) next
>[Switching to Thread
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #26 from Michael Haas ---
Created attachment 37273
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37273=edit
gdb with next
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #25 from Yann Ylavic ---
Bernhard, could you please "step" into apr_file_mktemp when reaching the
breakpoint (file "/tmp/modproxy.tmp.XX"), and once in hit "next" for the
entire apr_file_mktemp function?
--
You are receiving
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #24 from Bernhard Friedreich ---
(In reply to Rainer Jung from comment #22)
> Was mod_security also used in the original setup?
Do you mean my setup with "original setup"?
No we aren't using mod_security.
So we now have multiple
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #23 from Ruediger Pluem ---
The mod_proxy temporary files are created from the request pool (r->pool).
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #22 from Rainer Jung ---
Could it be this
https://github.com/SpiderLabs/ModSecurity/pull/2049
mod_security bug?
Commkits are:
https://github.com/SpiderLabs/ModSecurity/commit/d33f4ebc3fc3dcfbbc54113c76d2f3ed5a950598
and
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #21 from michael.h...@brz.gv.at ---
With mod_security it is the same 2.4.41 deletes the tmp file with 2.4.43 the
file is left in use on the filesystem.
here the gdb output from 2.4.41+2.4.43
=> 2.4.41
(gdb) break apr_file_mktemp
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
michael.h...@brz.gv.at changed:
What|Removed |Added
CC||michael.h...@brz.gv.at
--
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
Bernhard Friedreich changed:
What|Removed |Added
Status|RESOLVED|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
Bernhard Friedreich changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #18 from Bernhard Friedreich ---
Thats how our httpd is compiled:
./configure \
--prefix=/opt \
--enable-so \
--disable-userdir \
--enable-cache=shared \
--enable-cgi=shared \
--enable-expires=shared \
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #17 from Bernhard Friedreich ---
I've just reconfirmed in my local vm that the modproxy.tmp files are cleaned up
using httpd 2.4.41 but not with 2.4.43.
Only differences:
httpd: 2.4.41
mod_jk: 1.2.46
vs
httpd: 2.4.43
mod_jk:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #16 from Bernhard Friedreich ---
I've also tried via strace using those arguments:
strace -o /root/process_dump -ff /path/to/apache/bin/httpd -f
/path/to/apache/conf/httpd.conf -X
The only unlinks I could find where those:
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #15 from Bernhard Friedreich ---
I can now reproduce the problem in my local vm with a more or less stock
centos7 and our self compiled apache.
Running gdb the interesting thing is that file_cleanup is reached for apr-tmp
but
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #14 from Bernhard Friedreich ---
(In reply to Yann Ylavic from comment #13)
> Is there something special on your system that prevent opened file to be
> removed? It shouldn't be an issue on unix systems usually.
Between updating
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #13 from Yann Ylavic ---
(In reply to Ruediger Pluem from comment #11)
> Why should a failing cleanup kill the cleanup chain? If the cleanups are run
> by apr_pool_clear or apr_pool_destroy no return code is checked and the
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #12 from Yann Ylavic ---
(In reply to Bernhard Friedreich from comment #10)
> Is it also possible to attach to a running httpd? I don't have root
> permission on the server so I can only start apache using sudo with our
> systemd
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #11 from Ruediger Pluem ---
(In reply to Yann Ylavic from comment #5)
> I can only see a reason for the file to not be cleaned up: another request
> cleanup that runs before and fails (killing the cleanup chain).
Why should a
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #10 from Bernhard Friedreich ---
Is it also possible to attach to a running httpd? I don't have root permission
on the server so I can only start apache using sudo with our systemd unit. Is
it sufficient to connect to the parent
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #9 from Yann Ylavic ---
Comment on attachment 37252
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37252
gdb procedure
>(gdb) run
>Starting program: /path/to/httpd -f /path/to/httpd.conf -X
>[...]
># here httpd is waiting
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #8 from Yann Ylavic ---
Created attachment 37252
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37252=edit
gdb procedure
Here are the gdb steps for me to reach the cleanup point, does it work the same
for you?
--
You are
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #7 from Bernhard Friedreich ---
Here are the modules loaded (apachectl -M):
Loaded Modules:
core_module (static)
so_module (static)
http_module (static)
logio_module (shared)
mime_magic_module (shared)
expires_module (shared)
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #6 from Yann Ylavic ---
Also, since you can reproduce easily (I can't), can you run a debugger with
some instructions?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #5 from Yann Ylavic ---
I can only see a reason for the file to not be cleaned up: another request
cleanup that runs before and fails (killing the cleanup chain).
Which modules are in use?
--
You are receiving this mail
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #4 from Bernhard Friedreich ---
This is from the "main" errorlog. As already stated we are using a self
compiled Apache. There is nothing related in the vhost error logs..
--
You are receiving this mail because:
You are the
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #3 from Yann Ylavic ---
Did you also look at the main error log? I don't know if RHEL uses a single
error log file or one per vhost (plus the main one), so I ask..
--
You are receiving this mail because:
You are the assignee for
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #2 from Bernhard Friedreich ---
No nothing in error log. Only as disk was already full:
[Tue May 12 07:17:10.399683 2020] [proxy_http:error] [pid 31956:tid
139971851650816] (20014)Internal error (specific information not
https://bz.apache.org/bugzilla/show_bug.cgi?id=64452
--- Comment #1 from Yann Ylavic ---
Any particular message in error_log file (like "child pid xxx exit signal..")?
--
You are receiving this mail because:
You are the assignee for the bug.
45 matches
Mail list logo
