-----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-----
