> -----Original Message-----
> From: Garrett Cooper [mailto:[email protected]]
> Sent: Monday, February 22, 2010 4:11 PM
> To: Yuki Yao
> Cc: [email protected]
> Subject: Re: [LTP] "logrotate01" has problem
> 
> On Sun, Feb 21, 2010 at 6:06 PM, Yuki Yao <[email protected]> wrote:
> >> -----Original Message-----
> >> From: Garrett Cooper [mailto:[email protected]]
> >> Sent: Thursday, February 18, 2010 2:36 AM
> >> To: Rishikesh K Rajak
> >> Cc: Yuki Yao; [email protected]
> >> Subject: Re: [LTP] "logrotate01" has problem
> >>
> >> On Wed, Feb 17, 2010 at 7:02 AM, Rishikesh K Rajak
> >> <[email protected]> wrote:
> >> > On Mon, Feb 15, 2010 at 03:33:37PM +0900, Yuki Yao wrote:
> >> >> Hi,
> >> >>
> >> >> I contributed following problem previously, but it's not yet
revised.
> >> >> So, I contribute this again.
> >> >>
> >> >> After "./runltp" execution, all log files such as
"/var/log/messages*"
> >> >> disappeared, and there is only new log file created after the test.
> >> >>
> >> >> This seems a problem that occurs after the "logrotate01" test.
> >> >> I found that the past log files were deleted by forcing a
"logrotate"
> >> >> (logrotate -fv $LTPTMP/tst_logrotate.conf).
> >> >>
> >> >> Besides, logrotate01's shell script "./testcases/commands/logrotate
> >> >> /logrotate_tests.sh" creats logrotate configuration file ($LTPTMP
> >> >> /tst_logrotate.conf) for the test, and this configration file
includes
> >> >> "/etc/logrotate.d" as follows:
> >> >>
> >> >> [ ./testcases/commands/logrotate/logrotate_tests.sh line:156~ ]
> >> >> ----------
> >> >> # create config file.
> >> >>       cat >$LTPTMP/tst_logrotate.conf <<-EOF
> >> >>       #****** Begin Config file *******
> >> >>       # create new (empty) log files after rotating old ones
> >> >>       create
> >> >>
> >> >>       # compress the log files
> >> >>       compress
> >> >>
> >> >>       # RPM packages drop log rotation information into this
> directory
> >> >>       include /etc/logrotate.d
> >> >>
> >> >>       /var/log/tst_logfile {
> >> >>               rotate 5
> >> >>               weekly
> >> >>       }
> >> >>       #****** End Config file *******
> >> >>       EOF
> >> >> ----------
> >> >>
> >> >> By This, not only a log file for the test (/var/log/tst_logfile)
> >> >> but also 30 fies such as "/var/log/messages*" become "logrotate"
> >> >> command target.
> >> >> Only a log file for this test must become a target of the forced
> >> >> execution of "logrotate".
> >> >>
> >> >> To resolve this problem, we must change "/logrotate_tests.sh" not
> to
> >> >> include "/etc/logrotate.d", I think.
> >> >>
> >> >> Signed-off-by: Yuki Yao<[email protected]>
> >> >
> >> > Hello Garret,
> >> >
> >> > Any input for this patch ?
> >> >
> >> > Thanks
> >> > -Rishi
> >> >>
> >> >> Index: ./testcases/commands/logrotate/logrotate_tests.sh
> >> >> ============
> >> >>
> >>
> --- ./testcases/commands/logrotate/logrotate_tests.sh.orig    2008-10-
> >> 21
> >> >> 15:54:15.000000000 +0900
> >> >> +++ ./testcases/commands/logrotate/logrotate_tests.sh 2010-02-15
> >> >> 13:32:02.000000000 +0900
> >> >> @@ -163,7 +163,7 @@
> >> >>       compress
> >> >>
> >> >>       # RPM packages drop log rotation information into this
> directory
> >> >> -     include /etc/logrotate.d
> >> >> +     # include /etc/logrotate.d
> >> >>
> >> >>       /var/log/tst_logfile {
> >> >>               rotate 5
> >> >> @@ -200,7 +200,7 @@
> >> >>               # check if  /etc/logrotate.d is included/
> >> >>               # check if 5 rotations are forced.
> >> >>          # check if compression is done.
> >> >> -             grep "including /etc/logrotate.d"
> >> $LTPTMP/tst_logrotate.out
> >> >> \
> >> >> +             # grep "including /etc/logrotate.d"
> >> >> $LTPTMP/tst_logrotate.out \
> >> >>                       > $LTPTMP/tst_logrotate.err 2>&1 || RC=$?
> >> >>               grep "reading config file
> $LTPTMP/tst_logrotate.conf"
> >> \
> >> >>                       $LTPTMP/tst_logrotate.out   >
> >> >> $LTPTMP/tst_logrotate.err 2>&1 || RC=$?
> >> >> ============
> >>
> >> The problem statement isn't clearly worded, thus I'm confused whether
> >> or not the patch is fixing a symptom or the root cause itself.
> >
> > Hi,
> >
> > I want to explain about the problem and patch.
> >
> > <About Problem>
> > After "logrotate01" test, log files (such as "/var/log/messages*")
> > --which are important to system administration-- are disappeared.
> >
> > *** In the following explanation, I will call these important files
> >    "System-Logs" for convenience.
> >
> > The following explain about the problem.
> > 1. "logrotate01" tests the forced rotation "logrotate -f <config_file>".
> >   This rotation deletes the past log files which stored until now,
> >   and creates the new log file.
> >   The target of this forced rotation is /var/log/tst_logfile which
> >   created for this test.
> >
> > 2. $LTPTMP/tst_logrotate.conf is created as logrotate configuration
> >   file for this test.
> >   This config-file includes /etc/logrotate.d, and all files under
> >   /etc/logrotate.d are loaded.
> >
> > 3. In the files under the /etc/logrotate.d, the rotation of
> >   "System-Logs" are set.
> >
> > 4. Because, "System-Logs" also became a target for forced rotation.
> >   Therefore, after this test, all past "System-Logs" are disappeared.
> >
> > Only /var/log/tst_logfile should be the target of this test, I think.
> > What is the reason why actual "System-Logs" becomes the target?
> > In a system for exclusive use of the LTP test, this may not be problem.
> > But, it will be troubled that important logs disappeared when general
> > users execute runltp in the system which is operating.
> >
> > <About Patch>
> > The contributed patch doesn't load the file under the /etc/logrotate.d
> > by commenting-out "include /etc/logrotate.d" in
> $LTPTMP/tst_logrotate.conf.
> > And it can let only /var/log/tst_logfile be the target of the forced
> > rotation.
> 
>     So from what you described I see a singular problem: logrotate01
> should _restore_ a system log as that is a valid feature to test. I
> don't think that omitting that directive would be a wise idea because
> you're effectively disabling that functionality.
>     If you can make the test interrupt-resistant under normal
> conditions and restore on exit, you should be fine (hint... try
> something like the following)
> 
> save() {
>     cp "${SYSTEM_LOG}" "${SYSTEM_LOG}.bk"
> }
> 
> restore() {
>     # Disable the signal handler.
>     trap "" EXIT
> 
>     # Shouldn't be the case -- if so the test should be rewritten to
> use a mktemp generated file.
>     if [ "x${SYSTEM_LOG}" = "x${TEST_SYSTEM_LOG}" ] ; then
>         cp "${TEST_SYSTEM_LOG}" "${TEST_SYSTEM_LOG}.test"
>         TEST_SYSTEM_LOG="${TEST_SYSTEM_LOG}.test"
>     fi
> 
>     # XXX: Stop syslogd here...
> 
>     mv "${SYSTEM_LOG}.bk" "${SYSTEM_LOG}"
>     cat "${SYSTEM_LOG}.test" >> "${SYSTEM_LOG}"
> 
>     # XXX: Start syslogd again here...
> 
> }
> 
> # XXX: in ``main``, swap around the configuration; call save.
> 
> # Make sure restore will be called at the end of the script's lifetime.
> trap restore EXIT
> 
> # Do test stuff here..
> 

Hi, Garrett.

I think my patch (comment out "include") is more adroit process 
than your hint (back up SYSTEM_LOG.bk, and test against all SYSTEM_LOG,
then restore SYSTEM_LOG).

Because, "include" directive is only reading rotation infomation of 
SYSTEM_LOG which is the target of "logrotate".
Don't you think that only a rotation infomation of TEST_SYSTEM_LOG 
should be described in "tst_logrotate.conf" to make only TEST_SYSTEM_LOG 
the "logrotate" target?

Thanks, Yuki Yao

> Cheers,
> -Garrett



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Reply via email to