Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 928217 - Vdsm logs are filling filesystem up - logrotation of vdsm logs doesn't work correctly
Vdsm logs are filling filesystem up - logrotation of vdsm logs doesn't work c...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
3.1.3
All Linux
urgent Severity urgent
: ---
: 3.2.0
Assigned To: Douglas Schilling Landgraf
Artyom
infra
: ZStream
Depends On:
Blocks: 951612
  Show dependency treegraph
 
Reported: 2013-03-27 03:51 EDT by Tomas Dosek
Modified: 2016-02-10 14:05 EST (History)
22 users (show)

See Also:
Fixed In Version: vdsm-4.10.2.19.0
Doc Type: Bug Fix
Doc Text:
Previously, VDSM used FileHandler to manage the logs. FileHandler was replaced with WatchedFileHandler but /var/log/vdsm/libvirt.log was not included in WatchedFileHandler. This caused /var/log/vdsm/libvirt.log to expand endlessly, which led to cases in which the RHEV-H file system could fill with the libvirt log. libvirt.log has been removed, eliminating any chance that the RHEV-H filesystem could be filled with it.
Story Points: ---
Clone Of:
: 951612 (view as bug list)
Environment:
Last Closed: 2013-06-10 16:46:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 340123 None None None Never
oVirt gerrit 13728 None None None Never
Red Hat Product Errata RHSA-2013:0886 normal SHIPPED_LIVE Moderate: rhev 3.2 - vdsm security and bug fix update 2013-06-10 20:25:02 EDT

  None (edit)
Description Tomas Dosek 2013-03-27 03:51:16 EDT
Description of problem:

Vdsm logs are by default not properly rotated which causes the filesystem of hosts to fill up pretty easily. 

This is an issue especially with hosts that are configured just with disk space large enough only for hosts installation + few GB of logs (i.e. installation of host on SD card)

Version-Release number of selected component (if applicable):
4.10.*

How reproducible:
100 %

Steps to Reproduce:
1. Have a host with heavy load on it and few hundred VMs and just 12 GB of disk space.
  
Actual results:
Host filesystem is getting filled up by vdsm logs pretty easily, vdsm log size seems to be unlimited

Expected results:
logrotation should work correctly and host filesystem should not fill up

Additional info:

[root@i-mpapp1 ~]# lsof -a +L1 /var
COMMAND  PID USER   FD   TYPE  DEVICE   SIZE/OFF NLINK   NODE NAME
vdsm    9581 vdsm   12w   REG 253,137 3725208820     0 131486 /var/log/vdsm/libvirt.log.1 (deleted)
python  9601 root    4r   REG 253,137   17369349     0 131698 /var/log/vdsm/vdsm.log.1 (deleted)


Blamed git change:


New vdsm 4.10.* packages have removed "copytruncate" from /etc/logrotate.d/vdsm:

@@ -1,7 +1,6 @@
 /var/log/vdsm/*.log {
     rotate 100
     missingok
-    copytruncate
     size 15M
     compress
     compresscmd /usr/bin/xz


Apparently it's not needed any more: from ChangeLog:

2012-05-18  Mark Wu  <wudxw@linux.vnet.ibm.com>

        Change to use WatchedFileHandler instead of FileHandler in logger.conf
        We find that no new log message appears in log file after manually changing
        the vdsm log when vdsm is running. We have to restart vdsm to get logging
        work again. It could happen when people try to add some markers to pinpoint
        the related messages during toubleshooting. It's caused by the log file gets
        associated with a new inode after the manual change. To make logging survive
        the change, use WatchedFileHandler instead of FileHandler.

        In addition, WatchedFileHandler was provided specially for the external
        log rotate tools. It can notice that the log file change performed by
        logrotate, so we don't need to have the option 'copytruncate' in
        vdsm-logrotate.conf any more.

        Reported-by: Changming Bai <baichm@linux.vnet.ibm.com>


In etc/vdsm/logger.conf :
@@ -37,19 +37,20 @@
 propagate=0
 
 [handler_syslog]
+level=WARNING
 class=handlers.SysLogHandler
 formatter=sysform
-args=(('localhost', handlers.SYSLOG_UDP_PORT), handlers.SysLogHandler.LOG_USER)
+args=('/dev/log', handlers.SysLogHandler.LOG_USER)
 
 [handler_logfile]
-class=FileHandler
+class=logging.handlers.WatchedFileHandler
 args=('/var/log/vdsm/vdsm.log',)
 filters=storage.misc.TracebackRepeatFilter
 level=DEBUG
 formatter=long
 
 [handler_metadata]
-class=FileHandler
+class=logging.handlers.WatchedFileHandler
 args=('/var/log/vdsm/metadata.log',)
 level=WARNING
 formatter=long
@@ -69,7 +70,7 @@
 format: %(threadName)s::%(levelname)s::%(asctime)s::%(module)s::%(lineno)d::%(name)s::(%(funcName)s) %(message)s
Comment 7 Douglas Schilling Landgraf 2013-04-01 18:19:34 EDT
Hi all,

Thanks for your help
I have sent a patch to vdsm upstream to add the entry copytruncate to logrotate vdsm file avoiding to keep increasing the log forever because vdsm keep it opened.

Until next rhev-h version, I could suggest the following steps:

# vi /etc/logrotate.d/vdsm
- Add the entry:
copytruncate

# persist /etc/logrotate.d/vdsm

Restart vdsm daemon.

Cheers
Douglas
Comment 8 Douglas Schilling Landgraf 2013-04-02 08:56:03 EDT
Hello,

I have sent another patch upstream to change the rotation of logs.

===============
Logrotate compress VDSM logs (/var/log/vdsm/*) when they achieve >15M.
However, we rotates the logs only when it reaches 100 count.

This patch purpose the rotation to 10 counts because very old logs
cannot help to get out of trouble anyway. Also, reduce the number of
files/space in the partition.

Rotating 10 files compressed seems reasonable/safe.

http://gerrit.ovirt.org/#/c/13500/
=========================

Should we use more then 10 files rotating? 


Thanks
Douglas
Comment 9 Julio Entrena Perez 2013-04-02 09:09:07 EDT
(In reply to comment #8)

> Should we use more then 10 files rotating? 

Imvho we should keep a bit more than 10 files by default.
Current high vdsm verbosity means I sometimes end up looking at vdsm.log.30.xz to find the info I need.
Comment 10 Marina 2013-04-02 11:29:18 EDT
(In reply to comment #9)
> (In reply to comment #8)
> 
> > Should we use more then 10 files rotating? 
> 
> Imvho we should keep a bit more than 10 files by default.
> Current high vdsm verbosity means I sometimes end up looking at
> vdsm.log.30.xz to find the info I need.

I agree.
Comment 17 Artyom 2013-05-06 07:41:09 EDT
libvirtd logs saved under /var/log directory and not under /var/log/vdsm

libvirt-0.10.2-18.el6_4.4
vdsm-4.10.2-17.0.el6ev
sf15
Comment 19 Artyom 2013-05-16 03:04:31 EDT
libvirtd logs saved under /var/log directory and not under /var/log/vdsm

libvirt-0.10.2-18.el6_4.4
vdsm-4.10.2-18.0.el6ev
sf16
Comment 21 errata-xmlrpc 2013-06-10 16:46:51 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0886.html

Note You need to log in before you can comment on or make changes to this bug.