Excessive Log Files

Bug #488318 reported by sumguy
40
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Mediatomb
Confirmed
Undecided
Unassigned
mediatomb (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: mediatomb

Running mediatomb on 9.10 (32bit) cause a file, /var/log/mediatomb.log, to become excessively huge and fill all disk space on my root partition (~10gb).

Doing a quick search it seems at least I am not alone : http://wolfewebservices.com/blog/mediatomb-log-file-27gb

Also there does not seem to be any sort of configuration available in the /etc/mediatomb/config.xml to change where it writes it's logs to.

Tags: patch
Revision history for this message
ianr (mrzx4l-ubuntu) wrote :

Still doing this in 11.04 using mediatomb 0.12.1-0 as available in Ubuntu repositories. 97 gig file after running Mediatomb overnight, no wonder the database was corrupted, the disc was filled by the log file ;-)

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in mediatomb (Ubuntu):
status: New → Confirmed
Revision history for this message
mpompey (michael-pompey) wrote :

I can confirm that this is happening in 10.04 LTS in May 2012.

Revision history for this message
Amael (amael) wrote :

Hello,

I confirm this point : I just discovered a 63Gb size log file on my system after installing mediatomb yesterday.

Ubuntu 13.10
Mediatomb version: 0.12.1-0ubuntu5

Details :

amael@amserv:/var/log$ ls -lrt mediatomb.log
-rw-r--r-- 1 root root 63G avril 23 15:30 mediatomb.log
amael@amserv:/var/log$ head mediatomb.log
2014-04-23 14:51:55 INFO: Loading configuration from: /etc/mediatomb/config.xml
2014-04-23 14:51:55 INFO: UUID generated: a11c9192-6a31-4abb-95b3-6f2c2a5f6f8d
2014-04-23 14:51:55 INFO: Checking configuration...
2014-04-23 14:51:55 INFO: Migrating server configuration to config version 2
2014-04-23 14:51:55 INFO: Migration of configuration successfull
2014-04-23 14:51:55 INFO: Setting filesystem import charset to ANSI_X3.4-1968
2014-04-23 14:51:55 INFO: Setting metadata import charset to ANSI_X3.4-1968
2014-04-23 14:51:55 INFO: Setting playlist charset to ANSI_X3.4-1968
2014-04-23 14:51:55 WARNING: You enabled the YouTube feature, which allows you
                             to watch YouTube videos on your UPnP device!
amael@amserv:/var/log$ tail mediatomb.log
2014-04-23 15:30:44 ERROR: iconv: �res.mp3 could not be converted to new encoding: invalid character sequence!
2014-04-23 15:30:44 ERROR: iconv: Invalid or incomplete multibyte or wide character
2014-04-23 15:30:44 ERROR: iconv: 11.La boum à Cindy.mp3 could not be converted to new encoding: invalid character sequence!
2014-04-23 15:30:44 ERROR: iconv: Invalid or incomplete multibyte or wide character
2014-04-23 15:30:44 ERROR: iconv: � Cindy.mp3 could not be converted to new encoding: invalid character sequence!
2014-04-23 15:30:45 INFO: MediaTomb shutting down. Please wait...
2014-04-23 15:30:45 WARNING: skipping /home/amael/Téléchargements/Musique a trier/Zik cedric (metal)/Ensiferum (Finlande)/2004 - Iron/06 - Lost In Despair.mp3 : singleton is currently inactive!
2014-04-23 15:30:45 WARNING: skipping /home/amael/Téléchargements/Musique a trier/Zik cedric (metal)/Ensiferum (Finlande)/2004 - Iron/02 - Iron.mp3 : singleton is currently inactive!
2014-04-23 15:30:45 WARNING: skipping /home/amael/Téléchargements/Musique a trier/Zik cedric (metal)/Ensiferum (Finlande)/2004 - Iron/03 - Sword Chant.mp3 : singleton is currently inactive!
2014-04-23 15:30:45 INFO: Server terminating

affects: mediatomb (Ubuntu) → mediatomb
Changed in mediatomb (Ubuntu):
status: New → Confirmed
Revision history for this message
Matias Pecchia (mabeett) wrote :

I confirm this bug in Trusty :

Distributor ID: Ubuntu
Description: Ubuntu 14.04.2 LTS
Release: 14.04
Codename: trusty

mediatomb 0.12.1-5ubuntu2
mediatomb-common 0.12.1-5ubuntu2
mediatomb-daemon 0.12.1-5ubuntu2

Revision history for this message
Matias Pecchia (mabeett) wrote :

It seems the extreme verbosity is because of sqlite3.

I read just a bit the docs and I see that mediatomb and excluding the -l option there where be no logs.

IMO a well made patch should decrease sqlite3 verbosity.

With the attached patch the logging can be disable via /etc/default/mediatomb file.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "logging disable option via /etc/default/mediatomb" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
Revision history for this message
sordna (sordna) wrote :

There is a simple configuration bug, seeing it in 16.04 and 17.10 so it's everywhere.
The fix is VERY SIMPLE TOO.

The logrotate config script wants to rotate logfile: /var/log/mediatomb.log

But mediatomb is run with -l /var/log/mediatomb

The package maintainer should make them consistent. I downloaded the source and see this:

mediatomb-0.12.1-47-g7ab7616$ grep -r log/mediatomb .
./config/mediatomb-conf-fedora:MT_LOGFILE="/var/log/mediatomb"
./config/mediatomb-conf-optware:MT_LOGFILE="/opt/var/log/mediatomb"
./debian/mediatomb-daemon.mediatomb.default:MT_LOGFILE="/var/log/mediatomb"
./debian/mediatomb-daemon.mediatomb.upstart:env LOGFILE=/var/log/mediatomb.log
./debian/mediatomb-daemon.mediatomb.logrotate:"/var/log/mediatomb.log" {
./debian/mediatomb-daemon.postrm: rm -rf /var/log/mediatomb /var/log/mediatomb* \
./mediatomb.spec.in:/var/log/mediatomb {

Either mediatomb-daemon.mediatomb.default or mediatomb-daemon.mediatomb.logrotate should be updated so they both call the logfile with the same filename! Take your pick how the logfile should be named but make it consistent across the startup and logrotate configuration files :-)

Please fix asap now that the fix is finally identified, the bug has been open for too many years.

Revision history for this message
Robie Basak (racb) wrote :

@sordna, why did you subscribe me to this bug?

As far as I can tell this package is not being maintained in Debian and is pending deletion for this reason: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870936. A fork was mentioned in that bug. Is the fork packaged?

This specific bug may be the same as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633803.

To get this bug fixed properly, the best way would be to seek proper maintenance in Debian in the first instance. Then Ubuntu will be able to sync any fixes.

Until someone takes responsibility for this package, I don't think it's likely that bugs in it will get fixed.

Revision history for this message
sordna (sordna) wrote :

Hi Robie, I really appreciate your response. I subscribed you because "apt changelog" in my ubuntu 16.04 system shows you were the last person to update this package, so I thought you are the maintainer.
The bug you referenced is not the same (that bug is about mediatomb writing to the same logfile even after it is rotated to .1 etc)

The bug I am noticing is different: In ubuntu, mediatomb's logrotate config references "/var/log/mediatomb.log" but the startup script references "/var/log/mediatomb" so it does not get rotated at all.

All that is needed is to make them consistent by changing one of these 2 files.

Having said that, debian bug 633803 seems to affect Ubuntu as well, so there are 2 things to be fixed here. Thanks for pointing out there is a fork (gerbera) https://gerbera.io/
I am noticing even http://mediatomb.cc/ says development stopped and people should check out gerbera.
So I guess this is not worth fixing in mediatomb.

To anyone interested, here is the workaround to stop mediatomb from writing to the same logfile forever:
Edit /etc/logrotate.d/mediatomb and change: "/var/log/mediatomb.log" to: "/var/log/mediatomb"
and "invoke-rc.d mediatomb reload" to: "invoke-rc.d mediatomb restart"

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.