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!

Reply via email to