All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.