Sujet : Re: FileNotFoundError thrown due to file name in file, rather than file itself
De : torriem (at) *nospam* gmail.com (Michael Torrie)
Groupes : comp.lang.pythonDate : 14. Nov 2024, 16:44:56
Autres entêtes
Message-ID : <mailman.114.1731606301.4695.python-list@python.org>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1
On 11/14/24 12:03 AM, Left Right wrote:
On any Unix system this is untrue. Rotating a log file is quite simple:
I realized I posted this without cc'ing the list:
http://jdebp.info/FGA/do-not-use-logrotate.html .
The link above gives a more detailed description of why log rotation
on the Unix system is not only not simple, but is, in fact,
unreliable.
Nothing in that article contradicts what I said about renaming log
files. His argument is that renaming log files messes with tail -F, and
therefore broken and unreliable. Which a pretty strange argument. tail
-F might not see some data during the rotation, but the log files
themselves don't miss anything, which was my contention. In all my
years of sysadmin-ing I have never once worried about problems GNU tail
might have with a file that gets rotated out from under you. Not sure
why the author is so fixated on it.
There are actual legitimate issues at play, such as a mechanism for
informing the process to close the file (rotate usually requires
processes to respond to SIGHUP). And of course the disk can fill up
causing a denial of service of one kind or another. The latter is the
biggest source of problems.
Of course you could just log using the standard libc syslog facility.
Or better yet, start your process from a systemd unit file and let the
journal automatically log stderr. In both cases that would satisfy the
technical objections of the author of that little treatise.