Hash: SHA1

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.

I will be quoting the full text of each report so that it's clear what I've 

Wouter van der Schagt wrote:
>    1. *Execute:*
>       /home/vpopmail/bin/vadddomain domain.com test
>       /home/vpopmail/bin/vdeldomain domain.com
>       Results in: "Warning: Failed while attempting to delete domain
>       from auth backend".
>       This also happens on 5.4.25 (perhaps older as well) and 5.5
>       systems when the last_auth table does not yet exist. (see strace
>       output in previous emails)

Bug in tracker on SF.  I will probably just modify the domain deletion functions
in the MySQL module not to error if the lastauth table doesn't exist.

>     * *Execute:*
>       /home/vpopmail/bin/vusagec postmas...@domain.com
>       <mailto:postmas...@domain.com>
>       Results in: postmas...@domain.com <mailto:postmas...@domain.com>:
>       8198 byte(s) in 3 message(s) this is incorrect. There is only 1
>       message in this Maildir. To change maildirs quickly, use:
>       cd `emaildir postmas...@domain.com <mailto:postmas...@domain.com>`
>       As you can see, there is only 1 (disregarding the content). I am
>       guessing it is counting ./ and ../ as well. (2 * 4096 +6 = 8198).
>       Is this expected behavior?
>       At the same token, requesting totals for an entire domain
>       (/home/vpopmail/bin/vusagec @domain.com) results in: "domain.com:
>       8198 byte(s) in 0 message(s)". Here, while the bytes may be
>       correct, the total number of messages is not.

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 
when reporting bugs.

>     * 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 
surprised, but it's certainly possible.

Is there any chance you can copy the existing domain to this test environment?  
copying the domain over to the test environment will duplicate the issue so I 
debug it.

Many thanks again for allowing me to access your systems for testing!
- --
    Matt Brookings <m...@inter7.com>       GnuPG Key FAE0672C
    Software developer                     Systems technician
    Inter7 Internet Technologies, Inc.     (815)776-9465
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


Reply via email to