Jump to content

Logitech Media Server log file out of control


Recommended Posts



I've noticed that my Logitech Media Server docker creates a log file that just balloons out of control.  At one point it got to 80GB+ on my cache and caused my whole system to go unstable (see https://lime-technology.com/forums/topic/73395-all-my-dockers-are-missing-please-help)


Right now, it has gotten to 3GB in 2 weeks and is growing.    See server.log below:


root@unraid:/mnt/user/appdata/LogitechMediaServer/logs# ls -al --block-size=M
total 3337M
drwxrwxrwx 1 nobody users    1M Aug 14 22:41 ./
drwxrwxrwx 1 nobody users    1M Jul 17  2017 ../
-rw-rw-rw- 1 nobody users    0M Jul 17  2017 perfmon.log
-rw-rw-rw- 1 nobody users    1M Jul 19  2017 scanner.log
-rw-rw-rw- 1 nobody users 3337M Aug 31 18:04 server.log
-rw-rw-rw- 1 nobody users    1M Jul 18  2017 spotifyfamily1d.log

It is full of these errors (thousands of them continuously coming out):


[18-08-16 00:43:56.6065] Slim::Utils::Misc::msg (1252) Warning: [00:43:56.6063]
EV: error in callback (ignoring): Can't call method "display" on an undefined va
lue at /usr/share/perl5/Slim/Display/Lib/TextVFD.pm line 157.
[18-08-16 00:43:56.7562] Slim::Utils::Misc::msg (1252) Warning: [00:43:56.7561]
EV: error in callback (ignoring): Can't call method "display" on an undefined va
lue at /usr/share/perl5/Slim/Display/Lib/TextVFD.pm line 157.

Has anyone seen this error (google did not find much)?

Does anyone know how I can limit the size of the log, either just for this docker or for all dockers?


Thanks, -Glen.

Link to comment


I haven't tested this on my unRAID system, but in the past when I absolutely don't care about logs - and for whatever reason it's not convenient to edit rsyslog.conf - then you can always redirect a log to /dev/null

If this was just a normal log entry to /var/log/syslog I'd suggest just dropping it via rsyslog.conf - but as this is the 'docker' log - it's running via it's own syslog config - and while you can change that, it can be challenging to retain that change through updates.

For your use case, you could try the following:

- stop the docker (it's possible you might need to fully turn off the docker subsystem but I doubt that'll be required.

- delete the offending log file via:

rm -rf /mnt/user/appdata/LogitechMediaServer/logs/server.log

- make a symbolic link to /dev/null from your server.log file via:

ln -s /dev/null /mnt/user/appdata/LogitechMediaServer/logs/server.log

- turn on the docker again and check if that worked:

ls -lha /mnt/user/appdata/LogitechMediaServer/logs/


That should redirect all of the output to that log to /dev/null where it is magically compressed into nothingness and thus solve the issue.

Hope this helps,


Link to comment


This topic is now archived and is closed to further replies.

  • Create New...