public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: "Yuki Yao" <y_yao@ryobi.co.jp>
To: 'Garrett Cooper' <yanegomi@gmail.com>
Cc: ltp-list@lists.sourceforge.net
Subject: Re: [LTP] "logrotate01" has problem
Date: Fri, 5 Mar 2010 18:20:45 +0900	[thread overview]
Message-ID: <000801cabc45$2328c440$697a4cc0$@co.jp> (raw)
In-Reply-To: <364299f41002212310r6e8107c4m89d8970fdb8a9553@mail.gmail.com>

> -----Original Message-----
> From: Garrett Cooper [mailto:yanegomi@gmail.com]
> Sent: Monday, February 22, 2010 4:11 PM
> To: Yuki Yao
> Cc: ltp-list@lists.sourceforge.net
> Subject: Re: [LTP] "logrotate01" has problem
> 
> On Sun, Feb 21, 2010 at 6:06 PM, Yuki Yao <y_yao@ryobi.co.jp> wrote:
> >> -----Original Message-----
> >> From: Garrett Cooper [mailto:yanegomi@gmail.com]
> >> Sent: Thursday, February 18, 2010 2:36 AM
> >> To: Rishikesh K Rajak
> >> Cc: Yuki Yao; ltp-list@lists.sourceforge.net
> >> Subject: Re: [LTP] "logrotate01" has problem
> >>
> >> On Wed, Feb 17, 2010 at 7:02 AM, Rishikesh K Rajak
> >> <risrajak@linux.vnet.ibm.com> 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<y_yao@ryobi.co.jp>
> >> >
> >> > 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
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

      reply	other threads:[~2010-03-05  9:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-15  6:33 [LTP] "logrotate01" has problem Yuki Yao
2010-02-17 15:02 ` Rishikesh K Rajak
2010-02-17 17:36   ` Garrett Cooper
2010-02-22  2:06     ` Yuki Yao
2010-02-22  7:10       ` Garrett Cooper
2010-03-05  9:20         ` Yuki Yao [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000801cabc45$2328c440$697a4cc0$@co.jp' \
    --to=y_yao@ryobi.co.jp \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=yanegomi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox