Bug 637964
| Summary: | virt-top: The option --end-time of the virt-top doesn't work correctly | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Marcelo Moreira de Mello <mmello> |
| Component: | virt-top | Assignee: | Richard W.M. Jones <rjones> |
| Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.1 | CC: | dallan, kxiong, llim, ltroan, mmello, moshiro, myamazak, skito |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | virt-top-1.0.4-3.6.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-05-19 14:10:47 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 700575 | ||
Marcelo and I looked at this on IRC and it seems to be because of timezones. A simple reproducer is something like this: date ; virt-top --end-time +30 --debug /tmp/log --connect test:///default ; date If everything is working correctly then the time difference between the two dates would be roughly 30 seconds. In reality the time difference is 3 seconds (the default time between virt-top updates) *or* virt-top could appear to run forever. Look at /tmp/log for what virt-top thinks should be the end date. It's important to note (for customers) that what they experience will differ according to their timezone, so it could work for someone in GMT but fail for someone in another timezone. Better bug reproducer follows below. By setting the timezone (TZ) explicitly we can reproduce the timezone-related problem: $ date ; TZ=UTC virt-top --end-time +30 --debug /tmp/log --connect test:///default ; date Thu Jan 6 11:09:52 GMT 2011 Thu Jan 6 11:10:25 GMT 2011 $ date ; TZ=UTC-05 virt-top --end-time +30 --debug /tmp/log --connect test:///default ; date Thu Jan 6 11:11:01 GMT 2011 Thu Jan 6 11:11:04 GMT 2011 As you can see in the first case (TZ=UTC) virt-top works correctly. The difference in times is approx 30 seconds. In the second case (TZ=UTC-05) virt-top exits after the first screen update, approximately 3 seconds. Fix applied upstream: http://git.annexia.org/?p=virt-top.git;a=commitdiff;h=549a8eb860afd3ca7bec74c0a955b35855df0a5b Here is test result from Fujitsu.
It seems "--end-time" option is not really accurate.
Also, what is the expected behavior if we set both
"--end-time" and "-d" option.
Please see feedback from Fujitsu below.
<snip>
Thank you for the test package.
We verified it. As the result, we seem the fix isn't enough.
Please see below.
# rpm -q virt-top
virt-top-1.0.4-3.3.el6.x86_64
----------------------------------------------------
# time virt-top --end-time +10
ID S RDRQ WRRQ RXBY TXBY %CPU %MEM TIME NAME
5 R 0 0 104 0 2.7 8.0 27:32.35 SH_RHEL4.9_alpha_x86
<snip>
real 0m12.450s
user 0m0.045s
sys 0m0.014s
----------------------------------------------------
As you see, virt-top isn't completed at 10 seconds.
The completing time of virt-top is the almost same as --end-time +11,
--end-time +12. Please see the following two cases.
----------------------------------------------------
# time virt-top --end-time +11
virt-top 18:45:40 - x86_64 8/8CPU 2493MHz 11913MB
9 domains, 8 active, 6 running, 0 sleeping, 2 paused, 1 inactive D:0 O:0 X:0
CPU: 3.7% Mem: 8192 MB (8192 MB by guests)
ID S RDRQ WRRQ RXBY TXBY %CPU %MEM TIME NAME
7 R 0 8 52 0 0.9 8.0 20:36.70 SH_RHEL6.0PGA-x86
<snip>
real 0m12.449s
user 0m0.053s
sys 0m0.016s
----------------------------------------------------
# time virt-top --end-time +12
virt-top 18:47:00 - x86_64 8/8CPU 2493MHz 11913MB
9 domains, 8 active, 6 running, 0 sleeping, 2 paused, 1 inactive D:0 O:0 X:0
CPU: 10.0% Mem: 8192 MB (8192 MB by guests)
ID S RDRQ WRRQ RXBY TXBY %CPU %MEM TIME NAME
6 R 0 0 52 0 2.4 8.0 22:30.73 SH_RHEL5.5-x86
<snip>
real 0m12.456s
user 0m0.057s
sys 0m0.009s
----------------------------------------------------
As you see, those cases are completed at about 12 seconds.
We believe the behavior depends on a screen updates time.
(The default time is 3 seconds.)
If this goes on, the --end-time option won't be effectual when the large
value is specified with -d option. For instance:
----------------------------------------------------
# time virt-top -d 60 --end-time +10
virt-top 19:02:51 - x86_64 8/8CPU 2493MHz 11913MB
9 domains, 8 active, 6 running, 0 sleeping, 2 paused, 1 inactive D:0 O:0 X:0
CPU: 0.0% Mem: 8192 MB (8192 MB by guests)
ID S RDRQ WRRQ RXBY TXBY %CPU %MEM TIME NAME
5 R 0.0 8.0 30:59.27 SH_RHEL4.9_alpha_x86
<snip>
real 1m0.307s
user 0m0.022s
sys 0m0.007s
----------------------------------------------------
Since the "--end-time +10" was specified, virt-top should complete
at 10 seconds. However, it completes at about 60 seconds.
It means virt-top is completed at the time of a screen updates time.
</snip>
Let me post my test result. # rpm -q virt-top virt-top-1.0.4-3.3.el6.x86_64 # date; TZ=UTC+09 virt-top --end-time +10; date Wed Jan 12 11:20:32 JST 2011 Wed Jan 12 11:20:44 JST 2011 # date; TZ=UTC+09 virt-top --end-time +12; date Wed Jan 12 11:22:21 JST 2011 Wed Jan 12 11:22:36 JST 2011 # date; TZ=UTC+09 virt-top -d 60 --end-time +12; date Wed Jan 12 11:26:05 JST 2011 Wed Jan 12 11:27:05 JST 2011 Upstream fix: http://git.annexia.org/?p=virt-top.git;a=commitdiff;h=4e1409917c38f8bf57838f5119f58edbcad41937 I tested this on my production RHEL 6 server and it seems to work fine. Note if using 'date' to time the command that the output of date is only accurate to within a second; using it twice will be inaccurate by up to 2 seconds. You can use the following date option to get more accurate timings: date +'%s.%N' Verified with virt-top-1.0.4-3.7.el6.x86_64 1. time virt-top --end-time +10 real 0m10.497s user 0m0.018s sys 0m0.013s 2. time virt-top --end-time +12 real 0m11.569s user 0m0.026s sys 0m0.012s 3.date; TZ=UTC+09 virt-top -d 60 --end-time +12; date Mon Feb 21 20:30:32 CST 2011 Mon Feb 21 20:30:45 CST 2011 Now the --end-time can work correctly. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0720.html |
Description of problem: virt-top --end-time +<secs>" doesn't work as the specified time. Even if 300 is specified to <secs>, the virt-top completes in about 3 seconds. Please see below Version-Release number of selected component (if applicable): Red Hat Enterprise Linux Server release 6.0 (Santiago) virt-top-1.0.4-3.1.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. time virt-top --end-time +10 --debug /tmp/log Mon Sep 27 21:42:43 BST 2010 2. $ cat /tmp/log end time: 2010-09-27 20:43:04 Actual results: The problem may be related because it computes the end time in UTC, but compares it to the current time in the local timezone. Expected results: Execute in the time specified.