| 2016-09-21 18:19:06 |
David James |
bug |
|
|
added bug |
| 2016-09-21 18:20:21 |
David James |
description |
To recreate:
* I'm running Ubuntu Server 16.04.1 LTS (no GUI).
* I'm using byobu `5.106-0ubuntu1`.
* I press F1, then enable the "disk_io" notification, then choose "Apply".
* While doing nothing at the command prompt, I watch the status line.
What I expected to happen:
* I expected Byobu to report intermittent, fluctuation disk activity that corresponds to my activity on the system.
What I found to happen:
* Byobu's reports of disk_io did not correspond to the commands I was typing, nor reports from `iotop`.
Here are two examples:
* Example 1: On my system, "->372kB/s" (disk writing) remains on the status bar for an extended period.
My system is freshly installed, so I would be quite surprised if that exact amount of disk IO is happening for an extended period.
* Example 2: On my system, "<-912kB/s" (disk reading) remains on the status bar for an extended period.
I ran `iotop` to see what processes might be causing an ongoing disk activity. Nothing seemed to correspond.
Theory / Possible Explanation:
* It would appear that when disk activity changes from a non-zero value to zero, the previous value is not cleared out.
* This could be a simple matter of the TUI (text user interface) having a stale output, perhaps due to a rendering bug. |
To recreate:
* I'm running Ubuntu Server 16.04.1 LTS (no GUI).
* I'm using byobu `5.106-0ubuntu1`.
* I press F1, then enable the "disk_io" notification, then choose "Apply".
* While doing nothing at the command prompt, I watch the status line.
What I expected to happen:
* I expected Byobu disk_io report to fluctuate in obvious (or at least
believable) ways corresponding to my activity on the system.
What I found to happen:
* Byobu's reports of disk_io did not correspond to the commands I was typing, nor reports from `iotop`.
Here are two examples:
* Example 1: On my system, "->372kB/s" (disk writing) remains on the status bar for an extended period.
My system is freshly installed, so I would be quite surprised if that exact amount of disk IO is happening for an extended period.
* Example 2: On my system, "<-912kB/s" (disk reading) remains on the status bar for an extended period.
I ran `iotop` to see what processes might be causing an ongoing disk activity. Nothing seemed to correspond.
Theory / Possible Explanation:
* It would appear that when disk activity changes from a non-zero value to zero, the previous value is not cleared out.
* This could be a simple matter of the TUI (text user interface) having a stale output, perhaps due to a rendering bug. |
|
| 2016-09-21 18:25:26 |
David James |
description |
To recreate:
* I'm running Ubuntu Server 16.04.1 LTS (no GUI).
* I'm using byobu `5.106-0ubuntu1`.
* I press F1, then enable the "disk_io" notification, then choose "Apply".
* While doing nothing at the command prompt, I watch the status line.
What I expected to happen:
* I expected Byobu disk_io report to fluctuate in obvious (or at least
believable) ways corresponding to my activity on the system.
What I found to happen:
* Byobu's reports of disk_io did not correspond to the commands I was typing, nor reports from `iotop`.
Here are two examples:
* Example 1: On my system, "->372kB/s" (disk writing) remains on the status bar for an extended period.
My system is freshly installed, so I would be quite surprised if that exact amount of disk IO is happening for an extended period.
* Example 2: On my system, "<-912kB/s" (disk reading) remains on the status bar for an extended period.
I ran `iotop` to see what processes might be causing an ongoing disk activity. Nothing seemed to correspond.
Theory / Possible Explanation:
* It would appear that when disk activity changes from a non-zero value to zero, the previous value is not cleared out.
* This could be a simple matter of the TUI (text user interface) having a stale output, perhaps due to a rendering bug. |
To recreate:
* I'm running Ubuntu Server 16.04.1 LTS (no GUI).
* I'm using byobu `5.106-0ubuntu1`.
* I press F1, then enable the "disk_io" notification, then choose "Apply".
* While doing nothing at the command prompt, I watch the status line.
What I expected to happen:
* I expected Byobu disk_io report to fluctuate in obvious (or at least
believable) ways corresponding to my activity on the system.
What I found to happen:
* Byobu's reports of disk_io did not correspond to the commands I was typing, nor reports from `iotop`.
Notes:
* I am using a freshly installed system.
* I don't have many other processing running. I installed PostgreSQL, OpenSSH, and basic development tools.
For example, typing `dd -h` results in "<-72kB/s" (disk reading) remaining on the status bar for an extended period. I've waited for what seems to be several minutes but the status is not cleared.
I would be quite surprised if that exact amount of disk IO is happening for an extended period.
I ran `iotop` to see what processes might be causing an ongoing disk activity. Nothing seemed to correspond.
Theory / Possible Explanation:
* It would appear that when disk activity changes from a non-zero value to zero, the previous value is not cleared out.
* This could be a simple matter of the TUI (text user interface) having a stale output, perhaps due to a rendering bug. |
|
| 2016-09-21 18:27:20 |
David James |
description |
To recreate:
* I'm running Ubuntu Server 16.04.1 LTS (no GUI).
* I'm using byobu `5.106-0ubuntu1`.
* I press F1, then enable the "disk_io" notification, then choose "Apply".
* While doing nothing at the command prompt, I watch the status line.
What I expected to happen:
* I expected Byobu disk_io report to fluctuate in obvious (or at least
believable) ways corresponding to my activity on the system.
What I found to happen:
* Byobu's reports of disk_io did not correspond to the commands I was typing, nor reports from `iotop`.
Notes:
* I am using a freshly installed system.
* I don't have many other processing running. I installed PostgreSQL, OpenSSH, and basic development tools.
For example, typing `dd -h` results in "<-72kB/s" (disk reading) remaining on the status bar for an extended period. I've waited for what seems to be several minutes but the status is not cleared.
I would be quite surprised if that exact amount of disk IO is happening for an extended period.
I ran `iotop` to see what processes might be causing an ongoing disk activity. Nothing seemed to correspond.
Theory / Possible Explanation:
* It would appear that when disk activity changes from a non-zero value to zero, the previous value is not cleared out.
* This could be a simple matter of the TUI (text user interface) having a stale output, perhaps due to a rendering bug. |
To recreate:
* I'm running Ubuntu Server 16.04.1 LTS (no GUI).
* I'm using byobu `5.106-0ubuntu1`.
* I pressed F1, then enable the "disk_io" notification, then choose "Apply".
* I did various things on the command line. For example, I did nothing for several minutes. Then I ran `dd -h` at the command prompt. All the while, I watched the status line.
What I expected to happen:
* I expected Byobu disk_io report to fluctuate in obvious (or at least
believable) ways corresponding to my activity on the system.
What I found to happen:
* Byobu's reports of disk_io did not correspond to the commands I was typing, nor reports from `iotop`.
* In particular, running `dd -h` resulted in "<-72kB/s" (disk reading) remaining on the status bar for an extended period. I waited for what seems to be several minutes but the status is not cleared. I would be quite surprised if that exact amount of disk IO is happening for an extended period. I ran `iotop` to see what processes might be causing an ongoing disk activity. Nothing seemed to correspond.
Notes:
* I am using a freshly installed system.
* I don't have many other processing running. I installed PostgreSQL, OpenSSH, and basic development tools.
Theory / Possible Explanation:
* It would appear that when disk activity changes from a non-zero value to zero, the previous value is not cleared out.
* This could be a simple matter of the TUI (text user interface) having a stale output, perhaps due to a rendering bug. |
|
| 2016-09-21 18:27:48 |
David James |
description |
To recreate:
* I'm running Ubuntu Server 16.04.1 LTS (no GUI).
* I'm using byobu `5.106-0ubuntu1`.
* I pressed F1, then enable the "disk_io" notification, then choose "Apply".
* I did various things on the command line. For example, I did nothing for several minutes. Then I ran `dd -h` at the command prompt. All the while, I watched the status line.
What I expected to happen:
* I expected Byobu disk_io report to fluctuate in obvious (or at least
believable) ways corresponding to my activity on the system.
What I found to happen:
* Byobu's reports of disk_io did not correspond to the commands I was typing, nor reports from `iotop`.
* In particular, running `dd -h` resulted in "<-72kB/s" (disk reading) remaining on the status bar for an extended period. I waited for what seems to be several minutes but the status is not cleared. I would be quite surprised if that exact amount of disk IO is happening for an extended period. I ran `iotop` to see what processes might be causing an ongoing disk activity. Nothing seemed to correspond.
Notes:
* I am using a freshly installed system.
* I don't have many other processing running. I installed PostgreSQL, OpenSSH, and basic development tools.
Theory / Possible Explanation:
* It would appear that when disk activity changes from a non-zero value to zero, the previous value is not cleared out.
* This could be a simple matter of the TUI (text user interface) having a stale output, perhaps due to a rendering bug. |
To recreate:
* I'm running Ubuntu Server 16.04.1 LTS (no GUI).
* I'm using byobu `5.106-0ubuntu1`.
* I pressed F1, then enable the "disk_io" notification, then choose "Apply".
* I did various things on the command line. For example, I did nothing for several minutes. Then I ran `dd -h` at the command prompt. All the while, I watched the status line.
What I expected to happen:
* I expected Byobu disk_io report to fluctuate in obvious (or at least
believable) ways corresponding to my activity on the system.
What I found to happen:
* Byobu's reports of disk_io did not correspond to the commands I was typing, nor reports from `iotop`.
* In particular, running `dd -h` resulted in "<-72kB/s" (disk reading) remaining on the status bar for an extended period. I waited for what seems to be several minutes but the status was not cleared. I would be quite surprised if that exact amount of disk IO is happening for an extended period. I ran `iotop` to see what processes might be causing an ongoing disk activity. Nothing seemed to correspond.
Notes:
* I am using a freshly installed system.
* I don't have many other processing running. I installed PostgreSQL, OpenSSH, and basic development tools.
Theory / Possible Explanation:
* It would appear that when disk activity changes from a non-zero value to zero, the previous value is not cleared out.
* This could be a simple matter of the TUI (text user interface) having a stale output, perhaps due to a rendering bug. |
|
| 2018-08-12 13:08:22 |
Dustin Kirkland |
byobu (Ubuntu): importance |
Undecided |
Medium |
|
| 2019-06-15 01:33:48 |
Bryce Harrington |
affects |
byobu (Ubuntu) |
byobu |
|
| 2020-02-17 20:28:06 |
Launchpad Janitor |
branch linked |
|
lp:~gurnec/byobu/trunk-bugfix-1626218 |
|
