reopen 576180 thanks Martin Pitt wrote: > This would be a logrotate bug then. the logrotate.d file has > "missingok", which should be enough to stop logrotate from > complaining.
Not that I know. From logrotate(8): >> missingok >> If the log file is missing, go on to the next one >> without issuing an error message. See also nomissingok. As I understand it, this is to ignore the case a a (stopped?) server that produced no log during the last rotating period. Here, the directory /var/log/postgresql/ itself is missing, not the log file. So the problem is not that logrotate finds no log file, but rather that it is unable to glob the log path /var/log/postgresql/*.log. This produces messages like: >> /etc/cron.daily/logrotate: >> error: error accessing /var/log/postgresql: No such file or directory >> error: postgresql-common:1 glob failed for /var/log/postgresql/*.log I did not realize the point of postgresql-common, that is to allow running serveral versions of postgresql at the same time. Fixing this logrotate issue would be a little trickier, then. I see two solutions: * letting postgresql-common manage the log files of zero or more postgresql servers instead of one or more, by simply creating the /var/log/postgresql directory; * letting each postgresql-VERSION manage its log files by writing a more precise logrotate rule that only matches the log files of this version. The first one would be easier, but as I am discovering the simultaneous multiple-version system, I am not sure of what should be “the right thing to do”. -- Tanguy Ortolo
signature.asc
Description: Digital signature