Exim PanicLog has Non-Zero Size...?

Question

I'm getting the following error from my Ubuntu server:

exim paniclog /var/log/exim4/paniclog on (my server FQDN) has non-zero size, mail system might be broken.

I found a solution on the web here. Basically, I just need erase the paniclog by entering the following code:

sudo rm /var/log/exim4/paniclog

So, I know how to get rid of the error, but I don't know how it started, and how to not let it happen again. Any explanation? Thanks in advance.

Please post the contents of paniclog, to see the specific error that exim is generating, and then we can advise on how to keep the error from happening again. Exim is just doing its job and telling you that something unexpected happened :) — roadmr, Feb 17 '12 at 16:28
This question appears to be abandoned and unanswered, could you perhaps add more detail to your question? If this question no longer applies then you can either delete it or answer it yourself if you've solved the problem. Thanks! — Kevin Bowen, Mar 28 '13 at 10:56
The errors listed in paniclog have already been resolved in the OP's and my case. The bug being reported here is that despite those errors being resolved, the exim mail agent insists on keeping them in the paniclog and thus it continues to send you an email nightly (false positive). The solution is to delete the file, otherwise exim will continue to warn you about the already resolved error listed within it. @roadmr — oemb1905, Feb 11 '23 at 23:36
And/or to adjust logrotate settings or manually rotate them with logrotate. As for the OP's secondary question about "how it started" ... that can't be known once the paniclog is deleted, of course, but so long as you stop receiving the report after deletion or log rotation, then you know that whatever caused the paniclog report initially is now solved. In short, exim emails/reports daily false positives until the paniclog file is deleted or rotated. — oemb1905, Feb 12 '23 at 16:21

score 5 · Answer 1 · edited Sep 02 '21 at 12:43

5

The answers above are bad because you delete a log file and it's then gone for future log entries from exim. The solution is to create a logfile backup.

Most Debian based distros use logrotate for this. You can force a backup with the logrotate command. Option -f is to force it and -v is for a more verbose output.

Try (for Debian and also should work on Ubuntu).

sudo logrotate -f -v /etc/logrotate.d/exim4-paniclog

edited Sep 02 '21 at 12:43

Greenonline

2,030
8
20
27

answered Sep 01 '21 at 11:13

Jackfritt

63
1
6

Exim will create the paniclog file as soon as there is another error/panic. There's no harm in deleting the paniclog file so long as the error is resolved. @Jackfritt – oemb1905 Feb 11 '23 at 23:37
Agreed that deleting the paniclog file is not ideal. Folks should ideally understand why it reported the error in the first place. I added an answer that distinguishes between the originating cause of the paniclog and why people continue to get the report despite the issue already being fixed. Note: anyone who reports that deleting the file fixed the issue are actually reporting that they fixed the mis-configuration at some earlier point, which resulted in exim not regenerating paniclog upon it being deleted. – oemb1905 Feb 12 '23 at 16:41

score 5 · Answer 2 · edited Mar 02 '14 at 16:39

5

I had the same issue, here is what my exim4 paniclog looked like:

$ sudo cat /var/log/exim4/paniclog

2014-02-01 21:36:51 socket bind() to port 25 for address 127.0.0.1 failed: Address already in use: daemon abandoned
2014-02-01 22:03:33 socket bind() to port 25 for address 127.0.0.1 failed: Address already in use: daemon abandoned
2014-02-01 22:33:19 socket bind() to port 25 for address 127.0.0.1 failed: Address already in use: daemon abandoned
2014-02-01 22:36:33 socket bind() to port 25 for address 127.0.0.1 failed: Address already in use: daemon abandoned
2014-02-01 23:03:51 socket bind() to port 25 for address 127.0.0.1 failed: Address already in use: daemon abandoned
2014-02-01 23:14:31 socket bind() to port 25 for address 127.0.0.1 failed: Address already in use: daemon abandoned
2014-02-02 11:09:48 socket bind() to port 25 for address 127.0.0.1 failed: Address already in use: daemon abandoned

This problem was apparently solved by deleting the paniclog file

edited Mar 02 '14 at 16:39

s3lph

14,118
11
57
82

answered Mar 02 '14 at 16:08

Pascal V

77
1
2

8

Nope. It is not solved by deleting that file. – Olli Mar 02 '14 at 16:29
What does an occupied address have to do with a log file? @willbeeler check what application uses port 25 – s3lph Mar 02 '14 at 16:32
2

This IS the solution if the issue was temporary and the log file messages no longer apply. Delete the log to stop getting these panic warnings. – Eric Woodruff Dec 18 '15 at 06:17
Logs are always good – tread Apr 08 '16 at 18:49
yes worked.. restart exim after deleting – Abhishek Goel Jan 18 '17 at 17:03

David · Answer 3 · 2021-01-30T14:41:35.273

3

In my case the error was as follows:

exim paniclog on my-host has non-zero size

socket bind() to port 25 for address ::1 failed: cannot assign requested address: daemon abandoned

My solution was to remove the paniclog file and do a dpkg-reconfigure exim4-config removing ::1 from the IPs to bind to.

edited Jan 30 '21 at 14:41

answered Nov 14 '19 at 13:07

David

181
5

And how did you do this `dpkg reconfigure` exactly? I get : `dpkg: error: need an action option`, so there's more to the command. – Seamus Jan 15 '21 at 08:43
Thanks for trying this @Seamus It was in fact wrong, it's a whole word (`dpkg-reconfigure`). I've fixed the answer. – David Jan 30 '21 at 14:41
In your case, you received a paniclog error because you had an unresolved error. Upon fixing the error, you then ran a command which created a new paniclog file. Your post is about a socket error with ipv6, the OP's post was not about any particular error, but rather about how exim continued to mail them despite the error being resolved. – oemb1905 Feb 11 '23 at 23:39
Correction: The OP's post was about both topics, but the report was clearly a false positive or resolved prior because otherwise exim would have regenerated the file / report upon deleting it and the issue still being present. – oemb1905 Feb 12 '23 at 16:36

score 2 · Answer 4 · answered Feb 09 '15 at 10:56

In my case, the passwd file was missing, which was causing the exim4 to panic. I added a new user, and that added the file, with the proper permissions, and the content exim expects to be there.

It seems that exim needs at least one local user, and that domain had all forwarding users. Once I added a local user with a password, the errors stopped.

Your mileage may vary.

score 1 · Answer 5 · edited Jan 28 '19 at 03:28

1

This blog entry seems to have an answer. Looks like it can have to do with IPv6 settings and results from a change in the way the kernel supports IPv6.

Basically, disable IPv6 for now.

edited Jan 28 '19 at 03:28

Pablo Bianchi

14,308
4
74
117

answered Oct 16 '12 at 17:57

flickerfly

7,139
8
32
54

1

Whilst this may theoretically answer the question, [it would be preferable](http://meta.stackexchange.com/q/8259) to include the essential parts of the answer here, and provide the link for reference. – Kevin Bowen Mar 28 '13 at 10:54
5

And now we have the reasoning behind @KevinBowen 's comment. Your link is dead and now you're answer is meaningless without it. Please summarize and extract the relevant information from all links – Allison Aug 10 '17 at 17:33
My assumption at the time and still is that disabling IPv6 is a temporary solution. Disabling IPv6 shouldn't ever become a standard fix so this answer should be useless 5+ years in despite the reason it was done. – flickerfly Feb 06 '19 at 15:10
1

Ipv6 support is just one of many issues that can cause the non-zero size / paniclog report from exim's mail-agent, hardly the only cause. Moreover, even when that - or any other issue - is fixed, exim will continue to email/report the error until paniclog rotates or gets deleted. – oemb1905 Feb 12 '23 at 16:28

oemb1905 · Answer 6 · 2023-02-12T22:58:53.533

You get the "non-zero size" warning if you have an unresolved error reported in paniclog and/or even if you resolved the error, you will continue to receive an alert/email until you hit your logrotate rotation limit, delete the file, or adjust/instruct logrotate to archive it sooner.

Issue #1 - people are responding about particular errors in the paniclog which may or may not be related to the OP's. There are, however, hundreds of issues that can cause the same report.

Issue #2 - regardless of what error is in paniclog, exim will continue to email you (even when resolved / fixed) until the file rotates or is deleted.

It is important to disambiguate between particular misconfigurations causing the report / paniclog, and continuing to receive the report despite resolving the issue.

There is no harm in deleting the paniclog file. Exim will re-create the file if there is a new issue, or if you never fixed the initial issue. However, I agree with @Jackfritt that the proper way to address this is with logrotate, as that will help one debug the initial issue causing the report. However, solving that issue will not stop exim or its mail agent from continuing to send the report; that requires logrotate or deletion.

Exim PanicLog has Non-Zero Size...?

6 Answers6