> On April 4, 2014, 6:01 a.m., Rajani Karuturi wrote: > > systemvm/patches/debian/config/etc/init.d/cloud, line 36 > > <https://reviews.apache.org/r/19584/diff/2/?file=547785#file547785line36> > > > > Can we consider $CLOUD_DEBUG not set as true ie) log to cloud.out when > > $CLOUD_DEBUG is not set or $CLOUD_DEBUG is 1 ? > > > > redirect to /dev/null when $CLOUD_DEBUG is 0 > > > > this way, it wont change the default behaviour of it. whoever doesnt > > want logging can set the variable to 0
Since the earlier behaviour was causing the file system to fill up( which is a serious issue) , I would think that changing that and preventing the init script to write to cloud.out, should be useful. And if required logging can be turned on, any problems identified and turned off. - Saurav ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19584/#review39517 ----------------------------------------------------------- On April 3, 2014, 2:12 p.m., Saurav Lahiri wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/19584/ > ----------------------------------------------------------- > > (Updated April 3, 2014, 2:12 p.m.) > > > Review request for cloudstack. > > > Repository: cloudstack-git > > > Description > ------- > > This will prevent the /etc/init.d/cloud script from logging messages to > /var/log/cloud/cloud.out if the CLOUD_DEBUG flag is not defined. If the flag > is defined only then will messages be logged. This is because the cloud.out > file gets rolled over once max size is reached via the log4j settings, since > the script is not aware of the log4j settings it causes the log file to > exceed its max size and fill up the file system. > > > Diffs > ----- > > systemvm/patches/debian/config/etc/init.d/cloud 83853bc > > Diff: https://reviews.apache.org/r/19584/diff/ > > > Testing > ------- > > The console proxy vm was started and console sessions tested. The secondary > storage vm was succesfully started. > > > Thanks, > > Saurav Lahiri > >
