Bug 207611

i just found that yast still knows its sources.
how do i get those back into zmd?
refreshing them manually?

i tried to add all the sources back, which first didnt work because zmd forgot to unlock its database.

Anyways, I've set both log-level and syslog-level to "none" but /var/log/zmd-backend.log still keeps growing. just adding my installation sources back grew it from 0 bytes to over 60 megabytes! and since this source refresh happens at least once a day...

i added zmd-backend.log to logrotate, and got a nice shiny empty logfile.
then, i restarted zmd, which grew the logfile to FIFTY-SIX MEGABYTES!
just now, the simple action of "rug sl" added another THIRTY MEGABYTES!

btw, here's the output of "rug get -d|grep log:
mathias@pippin:/var/log> rug get -d |grep log
log-exception-traces      | False
log-level                 | off
log-soap-xml              | False
syslog-level              | off

So i think the fact that four reboots (or rather, 4 restarts of zmd) are enough to fill /var/log (on a separate partition of 512megs) are enough to make my system unusable should be considered a critical flaw.

just look at this:
pippin:/var/log # head -1 zmd-backend.log ; tail -1 zmd-backend.log ; du -sch zmd-backend.log
2006-09-24 23:00:32 <1> pippin(32508) [parse-metadata] parse-metadata.cc(main):139 -------------------------------------
2006-09-25 10:59:03 <1> pippin(26970) [media] MediaManager.cc(restoreAutoMounter):248 Restored HAL volume handling (automounter)
122M    zmd-backend.log
122M    total
pippin:/var/log #                       

its the first and the last line of zmd-backend.log. note the timestamps. note the size. tell me any valid reason for zmd being so chatty.

It's about the backend log.

Klaus, is this the bug you've fixed recently?

Yes. 

then put the fix out as an update to zmd... i'd even betatest it...
oh and btw, /var/log/Yast2 is growing fast, too.

Fixed for 10.2.

and where's the patch for 10.1?
i mean, this bug crippled my 10.1 machine once already... hence, reopened.

just to get my point across:
this morning my laptop wouldn't boot, again, due to /var/log full with 360megs of zmd-backend.log.

we are considering this fixed for 10.2, and we understand that NUE will use this bug to track a 10.1 patch.

Stano, please route this to the appropriate QA contact.

Adding log rollback and delete old versions. Reassigning to Chris. 

Need to be released as patch for 10.1 users. 

svn revision 35478 adds support for log-max-files-size preference in zmd.  This is the total size of all zmd-messages.log files to keep around.  The default is 50MB.  Zmd uses log4net, which has support for rotating and removing old logs.  This is fixed for 10.2.

I set the log4net properties to stay at 50MB in the 10.1/SLED10 branch.  I didn't add the preference here because it requires documentation and strings to be translated.

re #16:

> This is fixed for 10.2.

and this helps me how?
Remember, this bug was filed against 10.1. So, unless a patch for 10.1 is out, i can't consider this fixed.

Mathias, the bug is first resolved in the HEAD of development, and if PM decides to, it is then backported to the previous releases as a Suse patch. This is the first step in fixing the problem, and now the bug will go to QA.

Please watch your tone, as NUE has a standing practice to prioritize patient users over snappy ones so that the tone of the bugtracker remains civil.

assigning to Mauro for testing.

re #18:

Sorry, but this "we have a bug, we have a fix, we might not issue the fix for the current release, but we fix it in the next"-approach is not really helping to keep me patient.
With the sheer number of 10.1 bugs that got a "fixed for 10.2" in this bugtracker, 10.1 customers should get a 10.2 for free.

released for 10.1

is that the libzypp-1.3.2-0.9 that came by RUG yesterday?

thanks a lot, guys.

hm.

pippin:/var/log # head -1 zmd-backend.log; tail -1 zmd-backend.log; du -sch zmd-backend.log
2006-10-17 20:08:15 <1> pippin(13231) [parse-metadata] parse-metadata.cc(main):139 -------------------------------------
2006-10-17 20:14:09 <1> pippin(16328) [media] MediaManager.cc(restoreAutoMounter):248 Restored HAL volume handling (automounter)
2.7M    zmd-backend.log


close to 3 megs, just for starting zmd...

and the content looks like zmd is still stuck on log-level=debug even when configured for "fatal"...

And to put it out in the open, with log-level=fatal i expect nothing else than a timestamp like for starting zmd, a timestamp for stopping, and a line whenever an action fails to complete. For example, when zmd hits a 404 when getting a rpm file.

nothing more.

but still, its an improvement.