Scanner logs

[RobbH]

> mherger wrote:
>>
>> AFAIK LMS doesn't provide a logrotate configuration. It must have been
>> rotated by some default job.
>
> The Debian package does.

That's why I wrote "AFAIK". I should probably have used "IIRC" instead -
which would clearly blame my poor memory :-)

Thanks for the clarification!

[RobbH]

Scanner logs

In another thread this exchange caught my attention:

> Is there a way to have scanner.log contain multiple days of info, or
> does it always only contain the most recent scan?

Unfortunately it's overwritten with every scan run.

That was Michael, responding to user markm9999's question.

The answer surprised me, because I was certain that I had seen five previous scanner logs gzipped in the same directory, the same as with the server logs. And I was right:

42500 Sep 30 04:29 scanner.log
94319 Apr 14 2021 scanner.log.1.gz
94267 Apr 13 2021 scanner.log.2.gz
94031 Apr 12 2021 scanner.log.3.gz
94085 Apr 11 2021 scanner.log.4.gz
93993 Apr 10 2021 scanner.log.5.gz

Now that I open my eyes enough to see what's there, it's obvious that logrotate stopped processing scanner logs in April of last year. I assume that was a deliberate change, and I am sure there must have been a good reason for it. But I can't think what that reason might have been, and I am curious, so I would be grateful if someone would explain it.

This is just a matter of my own curiosity, trying to understand how things work. It is not a criticism or complaint!

currently running 8.3 (8.2 in April 2021) on Raspberry Pi OS.

[mrw]

Now that I open my eyes enough to see what's there, it's obvious that logrotate stopped processing scanner logs in April of last year. I assume that was a deliberate change, and I am sure there must have been a good reason for it.

The ”clue” does not show what you think it does.

What it almost certainly shows is that, on a number of days, your scanner logs exceeded 200k in size. And that logrotate duly rotated them as instructed, but before the next time the background scanner ran.

LMS erases the scanner log each time it starts a background scan, and has done for for more years than I have fingers. But if it has already been rotated, then there is nothing to erase !

Perhaps you had set some unusually verbose logging options for the period in question.

But it is, I think, an “unintended” result. Perhaps LMS’ logrotate configuration might be modified so as not to rotate the scanner log. Refer to the installed configuration file in /etc/logrotate.d. I don’t think I’d bother changing it.

[mherger]

Scanner logs

> But it is, I think, an “unintended” result. Perhaps LMS’ logrotate
> configuration might be modified so as not to rotate the scanner log.

AFAIK LMS doesn't provide a logrotate configuration. It must have been
rotated by some default job.

[mrw]

AFAIK LMS doesn't provide a logrotate configuration. It must have been
rotated by some default job.

The Debian package does. I don’t know about other platforms. It’s in ‘Slimserver platforms’.

https://github.com/Logitech/slimserver-platforms/tree/public/8.3/debian

[RobbH]

The ”clue” does not show what you think it does.

What it almost certainly shows is that, on a number of days, your scanner logs exceeded 200k in size. And that logrotate duly rotated them as instructed, but before the next time the background scanner ran.

LMS erases the scanner log each time it starts a background scan, and has done for for more years than I have fingers. But if it has already been rotated, then there is nothing to erase !

Perhaps you had set some unusually verbose logging options for the period in question.

But it is, I think, an “unintended” result. Perhaps LMS’ logrotate configuration might be modified so as not to rotate the scanner log. Refer to the installed configuration file in /etc/logrotate.d. I don’t think I’d bother changing it.

Thanks for that very enlightening explanation. As often happens, what I saw led me to a conclusion that was "simple, obvious... and wrong!"

[RobbH]

AFAIK LMS doesn't provide a logrotate configuration. It must have been
rotated by some default job.

The Debian package does. I don’t know about other platforms. It’s in ‘Slimserver platforms’....

I have LMS running on a Raspberry Pi, using the Debian-based Raspberry Pi OS. So I modified the file, /etc/logrotate.d/logitechmediaserver

After changing the scanner.log settings from "weekly" to "daily" and "size 200k" to "size 10k", I now have a backup of each day's scanner log. After five days, the oldest will be deleted each day.

I don't think there is any advantage to this, in most cases. There may be situations in which it's helpful to be able to refer to previous scanner logs, but I think that's a rare occurrence. In any case, it can be done, if it's needed.