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
findings.
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
vusage
daemon only returned byte counts. To fully support domain quotas it had
to
support message counts as well. This was added after the tarball was
created.
I installed the trunk on your system and it's working. If you're using
5.4.28,
use the trunk version rather than a tarball so that you're using the
latest version
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[21583]: 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
lies elsewhere.
* 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
failure
to avoid problems like this. 'Aack, child crashed' is a really
non-descriptive
error message that means the child process segfaulted.
This to me means that vdelivermail is segfaulting. It's hard for me to
say why
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
environment? Maybe
copying the domain over to the test environment will duplicate the issue
so I can
debug it.
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
'next' domain.
Sincerely,
- Wouter van der Schagt
!DSPAM:4a73eb4232711302398837!
