# Newsyslog equivalent for logrotate's copytruncate



## PenegalECI (Jan 24, 2017)

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,

Regards.


----------



## SirDice (Jan 24, 2017)

You could simply tell it to use syslog(3).


----------



## PenegalECI (Jan 24, 2017)

Yes, there is also that solution, but I need the PgSQL CSV log output, which can't be sent to `syslog`.


----------



## edg (Jun 12, 2018)

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.

Thx!


----------



## PMc (Jun 13, 2018)

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.


----------



## ShelLuser (Jun 13, 2018)

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.


----------



## edg (Jun 13, 2018)

Thanks for the explanation.


----------



## karolyi (Feb 23, 2019)

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/uwsgi.pid)
```
- Per configuration, uwsgi logs to /var/log/uwsgi/uwsgi.log.REAL:
in /etc/rc.conf

```
uwsgi_logfile="/var/log/uwsgi/uwsgi.log.REAL"
```

- 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/rotate-and-reload.sh
```

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.


----------

