Matt Brookings wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Harm van Tilborg wrote:
Well, I haven't checked other vpopmail binaries, since qmail was still
off at that moment. But at least vusaged was rejecting to run because of
it couldn't find libvpopmail.so. So I guess you haven't altered
vusaged's Makefile...
Could be the case. I will look into this.
Thanks!
I've included a patch that solves (i.e. uses the new quota_* functions)
at least get_user_size and get_domain_size inside vpopmail's daemon.
I appreciate this, but the maildirquota.c functions have been updated
to use the vusage daemon. They report their use because the functions
should no longer be called.
Haha, aw, I should've noticed that. At least now the warnings inside
vpopmaild are gone because of my patch :], but I understand this will
all go away in 5.5's final.
I think this behavior is caused by the fact that I have a symbolic link
inside each user directory that is using (Binc)IMAP. (Like
/home/vpopmail/domains/example.com/user/Maildir/INBOX points to
/home/vpopmail/domains/example.com/user/Maildir). And since all
functions inside vusaged use stat(2) calls, no symlinks are discovered.
I'm guessing this is resulting in some kind of a loop.
Hmm. Well, it's certainly possible. As you suspect, I don't believe the usage
daemon tests for symbolic links.
I've included a patch that solves this for my case. It checks whether
elements of /home/vpopmail/domains/example.com/user/Maildir are truely
directories - so no symlinks.
Individual usage works fine by now, however domain usage is not
calculated well. See below:
[cv] ~# ls -l /home/vpopmail/domains/example.com
total 28
drwx-- 3 vpopmail vchkpw 4096 2009-04-07 23:47 harm
drwx-- 3 vpopmail vchkpw 4096 2009-04-07 23:47 info
drwx-- 3 vpopmail vchkpw 4096 2009-04-07 23:44 postmaster
-rw--- 1 vpopmail vchkpw 468 2009-04-07 23:51 vpasswd
-rw--- 1 vpopmail vchkpw 2604 2009-04-07 23:51 vpasswd.cdb
drwx-- 3 vpopmail vchkpw 4096 2009-04-07 23:48 wilbert
[cv] ~# /home/vpopmail/bin/vusagec wilb...@example.com
wilb...@example.com: 1035916107 byte(s) in 5324 file(s)
[cv] ~# /home/vpopmail/bin/vusagec i...@example.com
i...@example.com: 594049032 byte(s) in 4041 file(s)
[cv] ~# /home/vpopmail/bin/vusagec h...@example.com
h...@example.com: 38496 byte(s) in 17 file(s)
[cv] ~# /home/vpopmail/bin/vusagec postmas...@example.com
postmas...@example.com: 8192 byte(s) in 2 file(s)
[cv] ~# /home/vpopmail/bin/vusagec @example.com
example.com: 3701844041 byte(s) in 20032 file(s)
[cv] ~# du -sb /home/vpopmail/domains/example.com
1631164507 /home/vpopmail/domains/example.com
Summing all usage values of individual users, I get:
1035916107 + 594049032 + 38496 + 8192 = 1630011827
That's nearly the same as `du' returns.
However, see what `vusagec' returns when I query `...@example.com'. That's
still an enormous difference. Has this maybe something to do with the
fact that example.com also has an alias example.org?
[cv] ~# /home/vpopmail/bin/vdominfo example.com
domain: example.com
uid:1009
gid:1004
dir:/home/vpopmail/domains/example.com
users: 1
quota: S=0,C=0
usage: 0% (3701844041 byte(s) in 20032 file(s))
alias: example.net
I notice some other things now too looking at this output: the number of
users is not correct (see directory listing above). And the fact that:
[cv] ~# cat /home/vpopmail/domains/example.com/vpasswd | wc -l
4
I've took a quick look, maybe `vdir' is not correctly shared between
`vdominfo.c' and `bigdir.c'?
And can you perhaps explain a little how the daemon globally works, it
caches all directories together with some timestamps (last check + last
modify time), however, what triggers the system to recheck everything,
etc. etc.
The Polling::Directory minimum poll time configuration determines how often
it polls individual directories (with some limitations).
And what exactly is the age configuration option for the daemon?
This configuration basically says that if a directory takes a long time to poll,
we artificially adjust it's next update time. The 'factor' is a multiplicative
of how long it took.
So, if a directory has 250,000 emails in it, and it took 3 minutes to poll it,
we don't want to poll that directory very often because what are the chances
someone is going to clean it out in the next poll time?
Clear, thanks!
- --
/*
Matt Brookings m...@inter7.com GnuPG Key D9414F70
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
iEYEARECAAYFAkolNGwACgkQ6QgvSNlBT3CiVQCfc4hLJiZyp5OmXD7KT0xiu9+D
WoEAoIeyg52pexNr693q3pKQ9L15DYiE
=r5lM
-END PGP SIGNATURE-
!DSPAM:4a25adb032685590333728!
--- userstore.vanilla.c 2009-06-02 18:47:14.0 +0200
+++ userstore.c 2009-06-02
