Summary: | sys-process/iotop fails to run | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Patrick Lauer <patrick> |
Component: | New packages | Assignee: | Justin Lecher (RETIRED) <jlec> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | jlec, orzel, xmw |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Patrick Lauer
2013-02-21 10:08:47 UTC
anything special on this box? (In reply to comment #1) > anything special on this box? Possibly vserver-sources kernel. Can't reproduce it on a different machine. Any debug output you need to figure out what's happening? let me point upstream to this. Perhaps we can get some answers there. Hello, got the same problem here. The box is a vserver as well. It fails with sys-process/iotop-0.5-r1 and sys-process/iotop-0.6. I could swear it once worked on this box, but I couldn't say if that was a previous version(0.4.4 here) or because of a change in kernel/vserver... The code that fails is about parsing /proc/xx/status. A quick python shows that the lines that fail are : VxID and NxID, which are exactly the lines that appear on my vserver and do not appear on any other box. So it's definitely a vserver-related box, and probably something that upstream should fix. (In reply to Thomas Capricelli from comment #5) > So it's definitely a vserver-related box, and probably something that vserver-related PROBLEM, of course (In reply to Thomas Capricelli from comment #5) > The code that fails is about parsing /proc/xx/status. A quick python shows > that the lines that fail are : VxID and NxID, which are exactly the lines > that appear on my vserver and do not appear on any other box. Can you please provide the output of `cat /proc/1/status` as an example, so that we can work on a patch? Thanks (In reply to Justin Lecher from comment #3) > let me point upstream to this. Perhaps we can get some answers there. Is there an upstream bug report to referred to, or did you write an email? (In reply to Michael Weber from comment #7) > (In reply to Justin Lecher from comment #3) > > let me point upstream to this. Perhaps we can get some answers there. > Is there an upstream bug report to referred to, or did you write an email? I drop him a mail, but never got a reply. (In reply to Michael Weber from comment #7) > Can you please provide the output of `cat /proc/1/status` as an example, so > that we can work on a patch? Thanks Sure. I thought we would just hope/wait for a fix upstream. ~ # cat /proc/1/status Name: init State: S (sleeping) Tgid: 1 Pid: 1 PPid: 0 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 64 Groups: VmPeak: 4216 kB VmSize: 4212 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 680 kB VmRSS: 652 kB VmData: 172 kB VmStk: 136 kB VmExe: 36 kB VmLib: 1780 kB VmPTE: 28 kB VmSwap: 16 kB Threads: 1 SigQ: 1/61420 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: fffffffe57f0d8fc SigCgt: 00000000280b2603 CapInh: 0000000000000000 CapPrm: 0000001fffffffff CapEff: 0000001fffffffff CapBnd: 0000001fffffffff Seccomp: 0 Cpus_allowed: 3 Cpus_allowed_list: 0-1 VxID: 0 NxID: 0 voluntary_ctxt_switches: 157787 nonvoluntary_ctxt_switches: 32 problem still present with sys-process/iotop-0.6 Dropped long ago What do you mean "dropped" ??? (In reply to Thomas Capricelli from comment #12) > What do you mean "dropped" ??? Didn't recognised that this issue still exists. We need to update the summary always. On the other hand, i can't confirm the bug. I've removed (emerge -C) and re-emerged iotop-0.6, and I can't reproduce the bug on the vserver where I had the bug. It might be that vserver was patched since then to produce correct output in /proc/*/status. For reference, the server is running 3.18.7-vs2.3.7.4, and was updated since my last confirmation (december 26th, 2014, almost one year ago). Debian iotop packager and upstream committer here. The initial bug report didn't mention what exception was thrown, but I am betting it is this: ValueError: need more than 1 value to unpack I am betting iotop is choking on this line: Groups: However, it is hard to tell because it was copy-pasted and that could have modified the content. Could someone who uses vserver attach a tarball containing their /proc/1/status file? If you can determine which process causes this and copy that one too, that would help fixing this. tar cf iotop-debug.tar /proc/1/status I've pushed a commit upstream that should fix this if it happens again: http://repo.or.cz/iotop.git/commitdiff/7814f30a5ed65acd07f284bba991ca557788ee80 (In reply to Paul Wise (Debian) from comment #16) > Could someone who uses vserver attach a tarball containing their > /proc/1/status file? If you can determine which process causes this and copy > that one too, that would help fixing this. > > tar cf iotop-debug.tar /proc/1/status You misread, there's an example of /proc/1/status in comment 9 + detailed explanations of what's going on. (In reply to Paul Wise (Debian) from comment #17) > I've pushed a commit upstream that should fix this if it happens again: > > http://repo.or.cz/iotop.git/commitdiff/ > 7814f30a5ed65acd07f284bba991ca557788ee80 Not sure this is needed anymore. With my kernel 4.1.25-vs2.3.8.4, i can confirm that even the VxID/NxID lines are exactly as others ("VxID:<tab>0"). (and iotop works well, unpatched) Comment 9 included spaces not tabs, in all of the fields, so it wasn't useful for checking this bug. Glad your kernel got fixed, the patch will be useful in case it ever gets reintroduced in another field though. |