-BEGIN PGP SIGNED MESSAGE-
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
investigated.
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
version
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
pretty
surprised, but it's certainly possible.
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.
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
*/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkpzDj0ACgkQIwet2/rgZywoRACghvMVkz8G5dvc9DQG1m34Pn/l
KGIAn0Qgjv7oFB/j+I8t42Ic3WoYJ1K2
=QctK
-END PGP SIGNATURE-
