22

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.

Improve this question
4
  • 2
    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, 2012 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, 2013 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, 2023 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, 2023 at 16:21

6 Answers 6

Reset to default
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

Improve this answer
5
  • 8
    Nope. It is not solved by deleting that file.
    – Olli
    Mar 2, 2014 at 16:29
  • What does an occupied address have to do with a log file? @willbeeler check what application uses port 25
    – s3lph
    Mar 2, 2014 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, 2015 at 6:17
  • Logs are always good
    – tread
    Apr 8, 2016 at 18:49
  • yes worked.. restart exim after deleting
    – Abhishek Goel
    Jan 18, 2017 at 17:03
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
Improve this answer
2
  • 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, 2023 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, 2023 at 16:41
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.

Improve this answer
4
  • 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, 2021 at 8: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, 2021 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, 2023 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, 2023 at 16:36
2

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.

Improve this answer
0
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.

Improve this answer
4
  • 1
    Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference.
    – Kevin Bowen
    Mar 28, 2013 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, 2017 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 6, 2019 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, 2023 at 16:28
-1

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .