Wietse Venema:
> Wietse Venema:
> > > The panic message says "%s" therefore this VBUF_SNPRINTF() call is
> > > made while formatting a string with an fmt value of "%s".
> >
> > Unfortunately, the panic call overwrites the format string that was
> > involved with the error, so the analysis for
Wietse Venema:
> > The panic message says "%s" therefore this VBUF_SNPRINTF() call is
> > made while formatting a string with an fmt value of "%s".
>
> Unfortunately, the panic call overwrites the format string that was
> involved with the error, so the analysis for width and precision
> is
Wietse Venema:
> A. Schulze:
> > postqueue: panic: vbuf_print: output for '%s' exceeds space 0
>
> Unfortunately, there is no way that I can reproduce this in
> postfix-3.2.0, given the preconditions in this code. Does this
> machine have ECC meory? Does it have a history of programs crashing?
>
A. Schulze:
> There are two strings looking like a queueid in this trace:
> 3xhXFj2Wt7z4FL3* and 3xhXDS3PqBz4FK9*
>
> that are two messages in the active queue just in the moment I run the
> command above.
> postfix delivered both messages as usual...
To clarify, this panic call happens with
A. Schulze:
off-list...
ok not "off list", my fault :-)
wietse:
OK, now please (install and) use ltrace. This provides more details
what happens in postqueue itself (strace gives insight into system
calls, i.e. the postqueue-kernel interface).
off-list...
I installed ltrace.
I modified pfqgrep: $mailq = "/usr/bin/ltrace /usr/sbin/postqueue -p
A. Schulze:
>
> wietse:
>
> > A. Schulze:
> >> postqueue: panic: vbuf_print: output for '%s' exceeds space 0
> >
>
> this is pfqgrep:
>
>$mailq = "/usr/sbin/postqueue -p |"; # added 'strace -f' here
>open(MAILQ, $mailq) or die;
>while () {
> # read from STDIN
>}
>
>
A. Schulze:
>
> wietse:
>
> > A. Schulze:
> >> postqueue: panic: vbuf_print: output for '%s' exceeds space 0
OK, now please (install and) use ltrace. This provides more details
what happens in postqueue itself (strace gives insight into system
calls, i.e. the postqueue-kernel interface).
wietse:
A. Schulze:
postqueue: panic: vbuf_print: output for '%s' exceeds space 0
this is pfqgrep:
$mailq = "/usr/sbin/postqueue -p |"; # added 'strace -f' here
open(MAILQ, $mailq) or die;
while () {
# read from STDIN
}
execve("/usr/sbin/postqueue", ["/usr/sbin/postqueue",
Pardon an amateur for jumping in here, but I think I see something:
On 8/26/2017 6:24 AM, A. Schulze wrote:
Now my script called pfqgrep -r "+truncated-domain" which trigger the
panic message sometimes
# pfqgrep -r '+12345678901'
Quantifier follows nothing in regex; marked by <-- HERE in m/+
A. Schulze:
> postqueue: panic: vbuf_print: output for '%s' exceeds space 0
Unfortunately, there is no way that I can reproduce this in
postfix-3.2.0, given the preconditions in this code. Does this
machine have ECC meory? Does it have a history of programs crashing?
Wietse
Message-ID:
A. Schulze:
> I'm Unsure what's the really wrong part (beside input santisation in
> my script) but I guess, postqueue should not panic...
To reduce the search space, it would help if you could provide
details of the postqueue command line. This gives some info about
what the program might be
Hello,
I found the message in my logs. It turns they where triggered by a
housekeeping script.
I did "qshape deferred" and used the first row (domainname) as
argument to pfqgrep -r
For long domainnames qshape shorten the output and prefix the domain
with a '+' character.
(described in
13 matches
Mail list logo
