To get back on this, what info do you need to debug this behavior?
Harm van Tilborg
Harm van Tilborg wrote:
Matt Brookings wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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
Could be the case. I will look into this.
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
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
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
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
usage: 0% (3701844041 byte(s) in 20032 file(s))
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
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,
The "Polling::Directory minimum poll time" configuration determines
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
of how long it took.
So, if a directory has 250,000 emails in it, and it took 3 minutes to
we don't want to poll that directory very often because what are the
someone is going to clean it out in the next poll time?
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
-----END PGP SIGNATURE-----