Mark,
Many thanks for the information, and apologies for my confusing mail.
The mail is silently dropped. I thought dmail was hanging from the way the log
just stopped part way through the attempt by dmail to deliver the mail and there
was no debug info about it cleaning up. However there is no dmail process
running and the mailfile is left in an intact state. Also subsequent writes
that don't take it over-quota are successful. So it's a procmail problem,
thanks for the insight.
I take your point about quotas, but this really is the last line of defense for
some very uncooperative users. Hopefully having lost mail and been
inconvenienced by this for several days might help him see the light.
Thanks again for your help
Season's greeting
John
John Landamore
School of Mathematics & Computer Science
University of Leicester
University Road, LEICESTER, LE1 7RH
[EMAIL PROTECTED]
Phone: +44 (0)116 2523410 Fax: +44 (0)116 2523604
>
>I'm confused. First you say that the mail "is silently dropped" when it
>would take the user over quota, then you say that "dmail hangs". Which is
>it?
>
>"Silently dropped" is a known behavior of procmail. You have to do
>something to cause an error from the delivery program to be passed back up
>to the mail delivery system. I don't know what it is, since I am not a
>procmail expert, but it apparently is more than just piping.
>
>"Hanging" is a different matter. c-client reacts to an appending write()
>error (including over-quota) by revoking the append and putting the
>mailbox file back to the way it was before.
>
>Unfortunately, it seems some UNIX variants, once it decides that the file
>is in "write error" status, keeps the file descriptor in that status even
>after the condition which caused it is corrected. The result is that the
>write() to put things back fails again. dmail doesn't know what to do
>other than try again, because it doesn't want to leave the file in a
>corrupted state.
>
>So that may be the cause of the hang; dmail is trying to revert the file
>back to the way it was before it started the append, but the operating
>system keeps on returning error.
>
>Note that this is supposition based upon empirical observations from third
>parties; I have never seen this behavior on any operating system that I
>use.
>
>If this is what is happening, then I don't know of anything (that I am not
>already doing) that would make the system let me write into the file
>again.
>
>In my humble opinion,...
>
>Hard disk quotas are a mistake. Historically, operating systems (all
>operating systems, not just UNIX) have *always* made hard disk quotas
>problematic for applications. It's not such much that a quota exceeded
>error can happen, but rather the variance in operating system behavior
>(even in different releases of the same OS) that make it difficult for an
>application to recover.
>
>It is a much more productive strategy to buy enough disk for user's needs.
>As the Dilbert cartoon says, "here's a quarter; now you can afford to
>double my disk quota."
>
>To check abusive behavior, soft disk quotas are preferable; allow the mail
>to be delivered, but then flag the account to start nagging the user to
>get under quota. It may be necessary to have a second level of flagging
>that stops mail delivery when if the user defies the nags and stays over
>quota, but never use hard disk quota.
>
>-- Mark --
>
>http://staff.washington.edu/mrc
>Science does not emerge from voting, party politics, or public debate.
>Si vis pacem, para bellum.
>
