If out of diskspace, greylistd spams the system log with "no space
left on device" messages at a rate of a couple dozen to more than a
thousand *per second*. Doesn't improve matters, of course, since very
quickly the space reserved for root is used up too. The syslog is
1.7G, and about 2M(!) are not "no space left on device" messages from
greylistd.

The subject is wrong, I realized on second thought: that's not
spamming, that's projectile vomitting. ;-)

Hi Jürgen,

thanks for your bug report.

In case of errors greylistd either uses stderr or syslog to inform about
the problem.
As greylistd does not know anything about the configuration of syslogd, it
is hard to decide whether data should be written to syslog or not. Just imagine
that the local syslogd is configured for remote logging.
So I am afraid the process that actually writes data into the file should
take care of disk usage.

Do you have any idea how to solve this issue? Otherwise I would like to
close that bug now ...

Best regards
Thorsten

Twice, this problem has forced me to reboot my server into single-user mode
to clean out these messages from my log file.  Each time, Debian has done a
large set of updates, which has had 'dpkg/apt' putting lots of .deb files
into '/var/cache/apt', which shouldn't be a problem by itself.  But if the
disk is a bit low on space and one then suffers a deny-of-service attack,
Linux can end up filling the partition containing '/var/log' with error
messages.

Ordinarily, disk full from a denial of service attack is something one can
recover from fairly easily as a super-user, as Linux assigns extra space
that ordinary users cannot use.  Alas, it appears that 'greylistd' quickly
fills all of that space with enumerable copies of the same error message:

   greylistd: Cannot write to /var/lib/greylistd/states.4009: No space left on device

I can think of a few ways to fix this problem.  First, duplicate error
messages could be suppressed.  One might do this by remembering the time
of the last disk full message at 'program/greylistd:286' and supressing
messages that have occurred too recently.  Or perhaps these errors could
be counted  and the number observed printed at a later time, say after
N seconds (or N minutes) or when another error message is generated.

Or, if the disk is full and the daemon cannot function anyway, it may as
well go to sleep and try again later.  If the sleep time is long enough,
it won't put enough messages in the log as to make a bad problem worse.

Another possible fix would be also record the time of the last disk-full
error, as above, and to check it at 'do_save()' [program/greylistd:286].
It would then not bother trying to save anything until enough time has
elapsed to make it worthwhile to try again.

While i know well at least a half-dozen programming languages, 'python'
is not one of them and i regret that i am not submitting a patch at this
time.
			     -- Tovar

This bit me again today.  In order to mitigate I've added the following
overrides to greylistd.service (with systemctl edit greylistd.service):

[Service]
LogRateLimitIntervalSec=10s
LogRateLimitBurst=10

The default limit is 10000 messages per 30s, hopefully limiting it to
1/s is enough to curtail the obscene disk usage when space is low.