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
