:: Re: [DNG] exim paniclog
Top Page
Delete this message
Reply to this message
Author: g4sra
Date:  
To: dng@lists.dyne.org
Subject: Re: [DNG] exim paniclog
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Monday, May 31, 2021 8:43 PM, Antony Stone <Antony.Stone@???> wrote:

> On Monday 31 May 2021 at 21:37:30, g4sra via Dng wrote:
>


> > > Is deleting the paniclog the proper way to stop receiving these e-mails?
> >


> > No, don't delete it, empty it, this should be the standard practice when
> > manually manipulating daemon log files.
>


> Hm, why do you say that?

Because I was taught to do it this way and the reasoning fits.
>


> Surely you want exim to open a new log file when it has something new to
> report.

To do that you would also need to to shut down and restart exim.

> If you do not delete the log file but simply write "nothing" to it in order to
> empty it, won't the daemon keep the current write position and then get
> confused when the file is smaller?

No. It actually appends the next write the the 'nothing' already in the file (the filepointer is moved by writing nothing, remember the OS filesystem holds the filepointer, exim holds a file descriptor).

Historically, not all daemons will create their log files, they will silently omit logging if they do not pre-exist.
Some daemons will not write to existing log files unless they have correct ownership and permissions (for security, plain text passwords in log files, or daemons that drop privileges).
Deleting a file does not delete any file descriptors held by other processes those processes will continue to write to the original file (it is possible to recover an unintentionally deleted file providing a process is holding a file descriptor as until it does, the file space is not unallocated for reuse).

Alternatively to my suggestion you could...

stop exim
delete /var/log/exim4/paniclog
recreate /var/log/exim4/paniclog with the correct user/mode permissions
start exim

I am both 'Old School' and lazy.