By default, messages printed from LUA log functions are sent both to
the configured log target and additionally to stderr (in most cases).
This introduces tune.lua.also-log-to-stderr for disabling that
second copy of the message being sent to stderr.
Addresses https://github.com/haproxy/haproxy/i
Hi Tristan,
On Tue, Oct 17, 2023 at 06:19:57PM +, Tristan wrote:
> By default, messages printed from LUA log functions are sent both to
> the configured log target and additionally to stderr (in most cases).
> This introduces tune.lua.also-log-to-stderr for disabling that
> second copy of the
Hi Guys,
I also have a suggestion, while at it:
SEND_ERR() which is used to report unexpected Lua errors (because of
improper API usage, or due to external factors such as IO/memory issues)
currently does a stderr duplication as in hlua_sendlog()
I'm thinking that it could be useful to make this
Hi Aurélien,
On Wed, Oct 18, 2023 at 09:32:19AM +0200, Aurelien DARRAGON wrote:
> Hi Guys,
>
> I also have a suggestion, while at it:
>
> SEND_ERR() which is used to report unexpected Lua errors (because of
> improper API usage, or due to external factors such as IO/memory issues)
> currently do
Hi Willy,
On 18/10/2023 07:47, Willy Tarreau wrote:
Hi Tristan,
...
I'm fine with the general approach, but I'm having two comments:
- using the word "also" in the option name is really not welcome
("tune.lua.also-log-to-stderr"), and actually more confusing than
without because
...
One last thing, SEND_ERR() reports to stderr through ha_alert() and
hlua_sendlog() does it through fprintf(stderr, ) by appending a static
header containing the log level, the date and the pid: maybe we should
try to unify those outputs as well?
I'm not sure anyone really *wants* to hav
On Wed, Oct 18, 2023 at 04:23:06PM +, Tristan wrote:
> Hi Willy,
>
>
> On 18/10/2023 07:47, Willy Tarreau wrote:
> > Hi Tristan,
> >
> > ...
> >
> > I'm fine with the general approach, but I'm having two comments:
> >
> >- using the word "also" in the option name is really not welcome
By the way, since we're talking about it, I think that actually it's not
logs that we're sending to stderr, it's Lua's alert messages that we're
sending both to stderr and logs.
Well I am no expert in what qualifies as "logs" vs "alerts", but the
messages sent from (for example) txn:Info() are
Hi Tristan,
On Wed, Oct 18, 2023 at 04:25:47PM +, Tristan wrote:
>
>
> > ...
> > > One last thing, SEND_ERR() reports to stderr through ha_alert() and
> > > hlua_sendlog() does it through fprintf(stderr, ) by appending a static
> > > header containing the log level, the date and the pid: may
Hi again Willy,
On 18/10/2023 07:47, Willy Tarreau wrote:
[...]
maybe we can have a 3rd value "auto" which would be the default
and which would only log to stderr if there's no other logger ? I
don't know if we have this info where it's used, though. Hmmm at
first glance we
On 20/10/2023 15:30, Tristan wrote:
ie in this snippet (hlua.c:1387):
static inline void hlua_sendlog(struct proxy *px, ...)
{
...
if (... && (!LIST_ISEMPTY(&px->loggers)))
return;
has the following results:
- locally from source => compiles happily
- locally from clone + p
Hi all again,
Here is the updated patch set after changes based on feedback received.
The change is now split across 2 patches.
Patch 0001 adding:
- tune.lua.log { on | off } (defaults to 'on') for usage of loggers
- tune.lua.log-stderr { on | auto | off } (defaults to 'on') for usage
of stderr
Hi Tristan,
Thanks for the nice work :)
Just my 2 cents, in the second patch, since you change the default
behavior, you forgot to update your comment from the 1st patch in Lua's
doc according to the new behavior:
> diff --git a/doc/lua.txt b/doc/lua.txt
> index 8d5561668..8d244ab3a 100644
> ---
> https://www.arpalert.org/haproxy-api.html (related txn:log()
> documentation:
> https://www.arpalert.org/src/haproxy-lua-api/2.9/index.html#core.log)
Forgot
https://www.arpalert.org/src/haproxy-lua-api/2.9/index.html#TXN.log as
well (both txn:log(), core:log() and friends with explicit log lev
Following up on Aurélien's remarks (thanks for catching my forgetting
it!), here's an additional patch to update the LUA-specific documentation.
Could be kept standalone or merged into the first patch, but to avoid
re-submitting the patchset already, here it is standalone for now.
Tristan
Fro
Hi Tristan,
On Fri, Oct 20, 2023 at 04:19:34PM +, Tristan wrote:
> Hi all again,
>
> Here is the updated patch set after changes based on feedback received.
Thanks for doing this work.
> The change is now split across 2 patches.
>
> Patch 0001 adding:
> - tune.lua.log { on | off } (default
Hi Willy,
On 23/10/2023 10:16, Willy Tarreau wrote:
No more comments, overall this looks good to me. Thus in summary, let's
try to avoid the ambiguity of "tune.lua.log" alone, and re-adjust the
bitfields. By the way, if we're having the same prefix "tune.lua.log"
for both options, it's an indica
On Mon, Oct 23, 2023 at 01:07:37PM +, Tristan wrote:
> Hi Willy,
>
> On 23/10/2023 10:16, Willy Tarreau wrote:
> > No more comments, overall this looks good to me. Thus in summary, let's
> > try to avoid the ambiguity of "tune.lua.log" alone, and re-adjust the
> > bitfields. By the way, if we'
> Overall it looks good to me as is. I'll let Aurélien have a quick look
> as well in case he sees anything but I'm personally fine with merging
> this.
Looks good to me as well, nice job Tristan :)
Just a side note regarding the comment from the 2nd patch: it's not
useful to mention the commit I
Thanks both for your time helping me with it :)
On 23/10/2023 14:34, Aurelien DARRAGON wrote:
Just a side note regarding the comment from the 2nd patch: it's not
useful to mention the commit ID from the previous patch given that the
effective commit ID will change when the patch will be applied
On 23/10/2023 14:38, Tristan wrote:
Thanks both for your time helping me with it :)
On 23/10/2023 14:34, Aurelien DARRAGON wrote:
Just a side note regarding the comment from the 2nd patch: it's not
useful to mention the commit ID from the previous patch given that the
effective commit ID will
> On that note, I assume the easiest is to let Willy alter the commit message
> to update (or remove) the commit reference when merging?
>
> Asking just in case you were waiting for me to send an amended patch for it.
Yeah I think so, and even if it's not amended, it's not dramatic: the
commit I
On Tue, Oct 24, 2023 at 11:41:56AM +, Tristan wrote:
>
> On 23/10/2023 14:38, Tristan wrote:
> > Thanks both for your time helping me with it :)
> >
> > On 23/10/2023 14:34, Aurelien DARRAGON wrote:
> > > Just a side note regarding the comment from the 2nd patch: it's not
> > > useful to ment
23 matches
Mail list logo
