Deadlock lua when calling register_task inside action function
Hi,
I am currently trying to send an http request for some incoming requests to a
logging server.
The incoming connection should be handled independent of the logging, so it
should be possible
that the incoming connection is already closed, while the logging is still in
progress.
I use lua to create a new http action. This action then registers a task to
decouple the logging.
And the rest happens inside this task.
As far as I understand the lua api documentation, it should be possible to call
`register_task` [1]
inside an action. However, HAProxy deadlocks when a request comes in.
My uneducated guess would be that HAProxy hangs in a spinlock because it tries
to create a lua context
while still executing lua.
I tested version 1.8.14 and 1.9.0 and they show the same behaviour.
The lua version is 5.3.5.
Am I missing something? Should this be possible at all?
gdb tells the following stacktrace. HAProxy never leaves the hlua_ctx_init
function:
#0 0x08eb8d04fd0f in hlua_ctx_init ()
#1 0x08eb8d0533f0 in ?? ()
#2 0x6de619c40d27 in ?? () from /usr/lib/liblua.so.5.3
#3 0x6de619c4db85 in ?? () from /usr/lib/liblua.so.5.3
#4 0x6de619c403b3 in ?? () from /usr/lib/liblua.so.5.3
#5 0x6de619c410a9 in lua_resume () from /usr/lib/liblua.so.5.3
#6 0x08eb8d04cf9a in ?? ()
#7 0x08eb8d05197e in ?? ()
#8 0x08eb8d05d037 in http_req_get_intercept_rule ()
#9 0x08eb8d063f96 in http_process_req_common ()
#10 0x08eb8d08f0f1 in process_stream ()
#11 0x08eb8d156b08 in process_runnable_tasks ()
#12 0x08eb8d0d443b in ?? ()
#13 0x08eb8d02b660 in main ()
haproxy.cfg:
global
lua-load mytest.lua
listen server
modehttp
bind :7999
http-request lua.test
server s 127.0.0.1:8081
mytest.lua:
function test(txn)
-- This works when commenting out the task creation
core.register_task(function()
core.Warning("Aha")
end)
end
core.register_action("test", { "http-req" }, test, 0)
Cheers,
Flakebi
[1]
https://www.arpalert.org/src/haproxy-lua-api/1.8/index.html#core.register_task
pgpz8uYSzbfax.pgp
Description: OpenPGP digital signature
Re: 1.9.1 coming soon (well, relatively soon)
Willy, Am 31.12.18 um 10:51 schrieb Willy Tarreau: > I expected to issue 1.9.1 by the end of last week, but spending time > working on unexpected issues postponed this a bit. I figured that it's > not the best week to expect anyone to deploy updates anyway so I'll > rather use the few remaining quiet days to address some pending bugs > and release something cleaner next week. > Now that 1.9 is out and 1.9.1 will fix the biggest after-release pain points: Can we possibly re-visit the infrastructure discussion "haproxy 1.9 status update" (2018-05-25), Message-ID 20180525161044.ga6...@1wt.eu: https://www.mail-archive.com/haproxy@formilux.org/msg30139.html Both as a user and a developer that got a few patches into haproxy I'm still missing a proper issue tracker :-) And continuous integration would certainly be helpful as well, no that we have a bug of reg-tests. Best regards Tim Düsterhus
Re: [PATCH] MINOR: acl: add support for TLS ALPN matching
On Mon, Dec 31, 2018 at 08:36:01PM -0500, Alex Zorin wrote: > On Tue, Jan 1, 2019, at 12:32 AM, Willy Tarreau wrote: > > You're welcome. I was about to apply it until I figured that a doc update > > is missing. Please add an entry to configuration.txt for this new keyword > > (and take care of respecting the alphabetical order). > > Okay, updated the docs. Perfect, this looks very good, and generally well documented (code, doc, commit), thank you! I've merged it now. > On reflection I was not able to discern the distinction of the sample fetch > keyword list and the ACL keyword list in payload.c. I hope that having added > this to the sample fetch list only was correct, even though it does not match > the example set by "req_ssl_sni". You're absolutely right. The ACLs are here for historic compatibility, they provide a default matching method, which most of the time is now properly picked thanks to the output type of the sample. Another difference often lies in the keyword name. For example "req_ssl_sni" used to be the name used in ACLs, while the sample fetch function is "req.ssl_sni", so there's nothing which can map one to the other automatically. The good choice is indeed to only add new keywords to the sample fetch list as you did, so that they can be used everywhere. Thanks, Willy
