Newsyslog equivalent for logrotate's copytruncate

Hello, there.

I'm trying to configure newsyslog to rotate PostgreSQL logs, but I ran into a problem: PostgreSQL can't be told to reopen its log files, unless by rebooting it, but I can't do that on a production server.

Under Linux, it is done using the copytruncate logrotate option, which instructs to copy the log file in the archive and then truncate the log file, instead of simply moving it away. This way, there is no need for the daemon to reopen its file, as it has not been moved. The thing is, I can't find newsyslog equivalent for this option. I could install logrotate, write my own log rotation script or use PgSQL integrated log file management, but that seems overkill, and I would be surprised to be forced to use something else than newsyslog. PostgreSQL is rather mainstream, so I assume there is a way to use newsyslog with it, but how? Did someone already encountered this problem? What was your solution?

Awaiting your answers,

Yes, there is also that solution, but I need the PgSQL CSV log output, which can't be sent to syslog.
Is syslog still the recommended approach for this?
I have a similar situation. In my case, I am rotating logs for a Ruby on Rails app, but I want to keep the application running. The solutions that I find are oriented towards Linux and recommend the copytruncate approach described by the original poster.

Concerning the "copytruncate" feature, I do not see that this could be built in a way that would not inherently lose data, so I consider that a hack and not a recommendable solution.

syslog is a working solution, and is already present on FreeBSD.
Using the logrotate that is built into postgres (options "log_rotation_age" etc.) would probably be another solution.

The thread opener's issue was to use the "csvlog" feature and destination, so syslog is ruled out.

But even such an issue can be solved by standard unix tools: Tell postgres to log to a fixed filename like "log/logfile.log", create a fifo (mkfifo()) with that name and also "log/logfile.csv", then use some program to constantly read from these fifos and do whatever you want with the data.
Last edited by a moderator:
The OP made the mistake of not using the right tool for the job. If you want to let PostgreSQL handle logging through use of the csvlog log destination (or any other file based destinations) then you should also let it handle rotation. Just use log_rotation_age and/or log_rotation_size optionally combined with the other logging settings.

Don't use external log processors for that, there's no need. Not even on Linux.

Of course if you wish to maintain full control over the logging procedure then using syslog is definitely something to consider, because this gives you much more flexibility. And of course if you do then newsyslogd does become a valid option again to sort logfile rotation.
Since nobody was able to provide a useful solution, I will.

I bumped into the same situation with newsyslog, and instead of letting the daemon log into syslog (which it has no place in), I created a small script that will be run from newsyslog upon log rotation.

Prerequisite is, you have to log into a separate file, that will be hard linked to the logfile you'll rotate (kinda the same thing newsyslog does on rotation).

Here's what I did with uwsgi:

- I created a small script that does the truncation of logfile and the reload of daemon:
#!/usr/bin/env sh

rm /var/log/uwsgi/uwsgi.log
ln /var/log/uwsgi/uwsgi.log.REAL /var/log/uwsgi/uwsgi.log
truncate -s 0 /var/log/uwsgi/uwsgi.log.REAL
kill -HUP $(cat /var/run/
- Per configuration, uwsgi logs to /var/log/uwsgi/uwsgi.log.REAL:
in /etc/rc.conf

- The last step is to tell newsyslog to run the script on log rotation instead of sending a HUP signal to uwsgi:
/var/log/uwsgi/uwsgi.log     root:wheel 640  70     *    $D5   JGPBR   /usr/local/etc/uwsgi/

This way the file that uwsgi holds open for logging (and cannot rotate) will be kept but truncated to 0, and uwsgi will be able to continue logging.