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

Attachment: signature.asc
Description: Digital signature

Reply via email to