Wouter, thank you for allowing me to connect to your test environment
remotely to determine what
was going on. I've CC'd the vchkpw list so the members can see my
No problem, thank you!
This was occurring because the most recent tarball for 5.4.28 does not
contain the updated code that handles message counts. Originally the
daemon only returned byte counts. To fully support domain quotas it had
support message counts as well. This was added after the tarball was
I installed the trunk on your system and it's working. If you're using
use the trunk version rather than a tarball so that you're using the
when reporting bugs.
Alright, will do. I have installed 5.4.28-rc1 at the moment on our
production servers and will let you know if anything comes up.
* Regarding the segmentation fault with vusaged, I cannot give / am
not allowed to give remote access. However I have ruled out file
system corruption and in the syslog I am getting: "Jul 30 08:45:19
mail2 kernel: [ 4492.236858] vusaged: segfault at 72656b79
ip b7dbb1d1 sp b2b10110 error 4 in
libmysqlclient.so.15.0.0[b7d4c000+1a3000]". I have upgraded the
server so it has libmysqlclient16 installed, but it still links
against libmysqlclient15. How can I modify this to try if this
solves the problem? I do not have this particular problem on other
servers and it is an older server that suffered 100% hd full
situations once or twice in the past, so it is possible the fault
* Regarding: the "deferral: Aack,_child_crashed._(#4.3.0)" message
in /var/log/qmail/current. I believe it happens when a message is
sent to a catch-all address (thus a non-existing mailbox), in
which case vusagec returns manually: "No data available", which is
seen as a crash. Could this possibly be the case? If so, perhaps
the error message can be more descriptive? Anyway, this causes
email to stay in the queue and not being delivered.
The client API does not treat *anything* from the vusage daemon as a
to avoid problems like this. 'Aack, child crashed' is a really
error message that means the child process segfaulted.
This to me means that vdelivermail is segfaulting. It's hard for me to
without access to the system. If it's happening within the client API,
I'd be pretty
surprised, but it's certainly possible.
How can I run vdelivermail manually to test if it is crashing?
Is there any chance you can copy the existing domain to this test
copying the domain over to the test environment will duplicate the issue
so I can
I'm going to try to do that this weekend. What I noticed was though. If I
remove the domain that is causing this beahavior the same happens to the
- Wouter van der Schagt