Matt Brookings wrote:
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 So I guess you haven't altered
vusaged's Makefile...

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/ points to
/home/vpopmail/domains/ 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/ 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/
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 1035916107 byte(s) in 5324 file(s)
[cv] ~# /home/vpopmail/bin/vusagec 594049032 byte(s) in 4041 file(s)
[cv] ~# /home/vpopmail/bin/vusagec 38496 byte(s) in 17 file(s)
[cv] ~# /home/vpopmail/bin/vusagec 8192 byte(s) in 2 file(s)
[cv] ~# /home/vpopmail/bin/vusagec 3701844041 byte(s) in 20032 file(s)
[cv] ~# du -sb /home/vpopmail/domains/
1631164507      /home/vpopmail/domains/

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 `'. That's still an enormous difference. Has this maybe something to do with the fact that also has an alias

[cv] ~# /home/vpopmail/bin/vdominfo
uid:    1009
gid:    1004
dir:    /home/vpopmail/domains/
users:  1
quota:  S=0,C=0
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/ | 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,
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 <>       GnuPG Key D9414F70
    Software developer                     Systems technician
    Inter7 Internet Technologies, Inc.     (815)776-9465
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


--- userstore.vanilla.c 2009-06-02 18:47:14.000000000 +0200
+++ userstore.c 2009-06-02 18:47:28.000000000 +0200
@@ -386,6 +386,27 @@

+                Check whether we really deal with directories
+         */
+         memset(b, 0, sizeof(b));
+         snprintf(b, sizeof(b), "%s/%s", u->path, e->d_name);
+         memset(&st, 0, sizeof(st));
+         ret = lstat(b, &st);
+         if ((ret == -1) || !(S_ISDIR(st.st_mode))) {
+                if ((ret == -1) && (errno != ENOENT) && (errno != ENOTDIR)) {
+                       fprintf(stderr, "userstore_find_directories: stat: %s: 
error %d\n", b, errno);
+                       closedir(dir);
+                       return 0;
+                }
+                /*
+                       Directory disappeared or not a directory
+                */
+                continue;
+         }
+         /*
                 Look for 'new' subdirectory


Reply via email to