The following is the GNU All-permissive License as recommended in https://www.gnu.org/licenses/license-recommendations.en.html

Copying and distribution of this file, with or without modification, are permitted in any medium without royalty provided the copyright notice and this notice are preserved. This file is offered as-is, without any warranty.

Contributions are welcome. See https://savannah.gnu.org/maintenance/fsf/.

exim paniclog on SOME_HOST has non-zero size

Investigate immediately! This ticket recurs often. This usually happens during a log rotate. Usually either exim will fail to write a log or clamav will fail to communicate with exim. If this only happens for a brief few seconds, this is acceptable and can be resolved without a message.

Always clear the paniclog so a ticket isn't created again the next day

tee -a /var/log/exim4/paniclog-archive </var/log/exim4/paniclog; echo -n >/var/log/exim4/paniclog

eggs.gnu.org clamd unable to connect to UNIX socket

The panic log reads several lines that look like this:

2019-05-23 09:36:41 [25461] 1xXxxx-0001xx-X1 malware acl condition: clamd: unable to connect to UNIX socket /var/run/clamav/clamd.ctl (Connection refused)

Log into eggs.

ssh root@eggs.gnu.org

See if clamd is running.

ps -ef | grep -i clamd

Restart clamd, if clamd is not running.

/etc/init.d/clamav-daemon restart

If clamd is running, everything is ok. clamd probably got stuck on scanning a message or attachment. Resolve the ticket.

Cannot open log file error

This is an ignorable error. This happens from time to time when the mainlog is being rotated. There will be a random message or few, then the error about the log file and that will be the only messages in the paniclog. You can verify by looking at the timestamp of the rotated log and the timestamp of the error message. If this only happens for a brief few seconds, this is acceptable and can be resolved without a message.

pipeheader smtp error

At least one message should be retried.

This could be caused by an overloaded system that requires adding memory or cpu or rebooting.

2020-07-28 17:41:19.892 [30256] 1k0XKc-0007nv-GI Delivery status for redacted@redacted.info: got 0 of 7 bytes (pipeheader) from transport process 30349 for transport smtp
2020-07-28 17:43:45.521 [31666] 1k0XMv-0008DR-PP Delivery status for redacted@redacted.info: got 0 of 7 bytes (pipeheader) from transport process 31675 for transport smtp

If there are just a few all with the same recipient, its probably a problem with the recipient's mail server. But, this always results in the message getting frozen and we generally want to do a retry, then check if they had the same error. If they result in the same error, unless they really look like they should be working (eg: they are to gmail or something), just clear the paniclog and leave them frozen. You can investigate the message more by doing exim -Mvh MESSAGEID and exim -Mvb MESSAGEID

exim -M 1k0XKc-0007nv-GI 1k0XMv-0008DR-PP
cat /var/log/exim4/paniclog

If you suspect there is an overload problem, load up munin stats for that period. Do an immediate retry of some messages and watch the log:

tail -f /var/log/exim4/mainlog | grep 1k0XKc-0007nv-GI
# separate terminal:
exim -M 1k0XKc-0007nv-GI