You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Check the bug
Before filling this bug report, please search if a similar issue already exists.
In this case, just add a comment on this existing issue.
Describe the bug
WebUI shows "8736h 00:00" in time column for every entry in the process list. Only happens in the web UI
To Reproduce
Steps to reproduce the behavior:
Start Glances with the following options '-w'
Open web UI and look at process list
Expected behavior
Show the process time as the curses UI does
Screenshots
Screenshot of web UI showing wrong time for all processes
Environement (please complete the following information)
Operating System (lsb_release -a or OS name/version): Arch Linux
Glances & psutil versions: Glances v4.1.2, Glances API version 4, PsUtil v6.0.0
How do you install Glances (Pypi package, script, package manager, source): Official Arch package, AUR package glances-git, and source from develop branch
Additional context
I did a bit of trying to track down the problem in hopes of doing a PR instead of this, but I couldn't fix it myself. Here's what I found in my testing tonight though.
The file glances/outputs/static/js/filters.js was giving me a couple problems. The timemillis function seemed to be problematic. I don't have a great understanding currently of how the web side of Glances interacts with itself, but I did some testing with what I believe are the values that were being given to it, coming from the API at /api/4/processlist. Specifically, I grabbed one process' cpu_times values, which was:
Running Node and passing that object to timemillis returned 0. It seemed to me that the for loop was failing to iterate over the object. Changing timemillis to iterate over the keys (for (var key in array)) got me an actual number out of it.
Looking then at timedelta:
d ends up representing 1970-01-01T00:00:00.000Z when sum is 0
My guess is that the math around Date is not acting as expected, but that's all I've got with my current understanding of the code.
I don't currently know where else those two functions are used, if anywhere, but I'm planning to give more of a look later. Assuming I don't find anything else relying on these, I'll try gutting and remaking those functions, and opening a PR after some testing if it turns out well.
The text was updated successfully, but these errors were encountered:
Check the bug
Before filling this bug report, please search if a similar issue already exists.
In this case, just add a comment on this existing issue.
Describe the bug
WebUI shows "8736h 00:00" in time column for every entry in the process list. Only happens in the web UI
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Show the process time as the curses UI does
Screenshots
Screenshot of web UI showing wrong time for all processes
Environement (please complete the following information)
glances-git
, and source from develop branchAdditional context
I did a bit of trying to track down the problem in hopes of doing a PR instead of this, but I couldn't fix it myself. Here's what I found in my testing tonight though.
The file glances/outputs/static/js/filters.js was giving me a couple problems. The
timemillis
function seemed to be problematic. I don't have a great understanding currently of how the web side of Glances interacts with itself, but I did some testing with what I believe are the values that were being given to it, coming from the API at/api/4/processlist
. Specifically, I grabbed one process'cpu_times
values, which was:Running Node and passing that object to
timemillis
returned 0. It seemed to me that the for loop was failing to iterate over the object. Changingtimemillis
to iterate over the keys (for (var key in array)
) got me an actual number out of it.Looking then at
timedelta
:d
ends up representing1970-01-01T00:00:00.000Z
when sum is 0doy
results in 365My guess is that the math around Date is not acting as expected, but that's all I've got with my current understanding of the code.
I don't currently know where else those two functions are used, if anywhere, but I'm planning to give more of a look later. Assuming I don't find anything else relying on these, I'll try gutting and remaking those functions, and opening a PR after some testing if it turns out well.
The text was updated successfully, but these errors were encountered: