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..
Cheers,
-Garrett
------------------------------------------------------------------------------
Download Intel® 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