Description of problem: CTID doesn't show (openvz) container id Version-Release number of selected component (if applicable): htop-2.2.0-3.el7.x86_64 How reproducible: always Steps to Reproduce: 1. running on vzkernel-3.10.0-862.20.2.vz7.73.29.x86_64 2. start container(s) 3. launch htop (on HN) 4. show CTID column Actual results: CTID 0 for all processes Expected results: correct container IDs Additional info:
It looks like the build does use --enable-openvz and looking at the htop code it attempts to pick out a container ID as the final field of /proc/PID/stat - could you add an example output from: "cat /proc/self/stat" on a system running an OpenVZ kernel?
in /proc/*/status i use envID, not MMUB or TaskUB. Not sure which of the 3 last fields to use in /proc/*/stat. here examples from both rhel6 and centos7. first rhel6, example container id: 166 #caper# cat /etc/redhat-release;uname -a;p=8308;ps $p;head -99 /proc/$p/stat{,us} Red Hat Enterprise Linux Server release 6.5 (Santiago) Linux caper 2.6.32-042stab145.3 #1 SMP Thu Jun 11 14:05:04 MSK 2020 x86_64 x86_64 x86_64 GNU/Linux PID TTY STAT TIME COMMAND 8308 ? Ss 0:05 init ==> /proc/8308/stat <== 8308 (init) S 1 8308 8308 0 -1 4202752 832 157242705 32 1000 144 420 150199 52249 20 0 1 0 6781 19697664 197 18446744073709551615 94308086190080 94308086330580 140721254222176 140721254221256 140083900077699 0 0 4096 536962595 18446744071580818889 0 0 17 0 0 0 19 0 0 0 0 0 0 0 1 166 166 166 ==> /proc/8308/status <== Name: initState: S (sleeping) Tgid: 8308 Pid: 8308 PPid: 1 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 Utrace: 0 FDSize: 64 Groups: envID: 166 VPid: 1 StopState: 0 VmPeak: 19248 kB VmSize: 19236 kB VmLck: 0 kB VmHWM: 1468 kB VmRSS: 788 kB VmData: 200 kB VmStk: 84 kB VmExe: 140 kB VmLib: 2356 kB VmPTE: 60 kB VmPTD: 28 kB VmSwap: 144 kB Threads: 1 SigQ: 0/30924 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000001000 SigCgt: 00000001a0016623 SigSvd: 0000000000000000 CapInh: 00000000fdccefff CapPrm: 00000000fdccefff CapEff: 00000000fdccefff CapBnd: 00000000fdccefff Speculation_Store_Bypass: not vulnerable Cpus_allowed: 3 Cpus_allowed_list: 0-1 Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 Mems_allowed_list: 0 voluntary_ctxt_switches: 86599 nonvoluntary_ctxt_switches: 948 TaskUB: 166 MMUB: 166 here's centos7, note example container id's: 165 and 10000000-0000-0000-0000-000000000199 #umari# cat /etc/redhat-release;uname -a;p='2547 2732';ps $p;eval head -99 /proc/{${p// /,}}/stat{,us} CentOS Linux release 7.8.2003 (Core) Linux umari 3.10.0-1127.8.2.vz7.151.10 #1 SMP Mon Jun 1 19:05:52 MSK 2020 x86_64 x86_64 x86_64 GNU/Linux PID TTY STAT TIME COMMAND 2547 ? Ss 0:09 init 2732 ? Ss 0:06 init ==> /proc/2547/stat <== 2547 (init) S 1 2547 2547 0 -1 1077944576 413 99164908 15 64331 227 741 13527283 2482911 20 0 1 0 5216 19746816 108 18446744073709551615 94398394626048 94398394766548 140720697690544 140720697689624 140556359173763 0 0 4096 536962595 18446744072330174341 0 0 17 0 0 0 39 0 0 94398396865848 94398396871408 94398405701632 14 0720697692061 140720697692076 140720697692076 140720697692141 0 0 0 0 0 0 1 10000000-0000-0000-0000-000000000199 10000000-0000-0000-0000-000000000199 10000000-0000-0000-0000-000000000199 ==> /proc/2732/stat <== 2732 (init) S 1 2732 2732 0 -1 1077944576 421 60156747 8 1140 138 474 131392 58822 20 0 1 0 5534 19746816 52 18446744073709551615 94109182414848 94109182555348 140728559531520 140728559530600 139829054359171 0 0 4096 536962595 18446744072330174341 0 0 17 0 0 0 48 0 0 94109184654648 94109184660208 94109187067904 140728559 538110 140728559538125 140728559538125 140728559538157 0 0 0 0 0 0 1 165 165 165 ==> /proc/2547/status <== Name: init Umask: 0022 State: S (sleeping) Tgid: 2547 Ngid: 0 Pid: 2547 PPid: 1 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 64 Groups: NStgid: 2547 1 NSpid: 2547 1 NSpgid: 2547 1 NSsid: 2547 1 envID: 10000000-0000-0000-0000-000000000199 VPid: 1 VmPeak: 19300 kB VmSize: 19284 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 2284 kB VmRSS: 432 kB RssAnon: 100 kB RssFile: 332 kB RssShmem: 0 kB VmData: 200 kB VmStk: 132 kB VmExe: 140 kB VmLib: 2356 kB VmPTE: 60 kB VmSwap: 140 kB Threads: 1 SigQ: 0/30936 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000001000 SigCgt: 00000001a0016623 SigSvd: 0000000000000000 CapInh: 0000000000000000 CapPrm: 0000001fffffffff CapEff: 0000001fffffffff CapBnd: 0000001fffffffff CapAmb: 0000000000000000 NoNewPrivs: 0 Seccomp: 0 Speculation_Store_Bypass: not vulnerable Cpus_allowed: 3 Cpus_allowed_list: 0-1 Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 Mems_allowed_list: 0 voluntary_ctxt_switches: 129690 nonvoluntary_ctxt_switches: 2226 TaskUB: 10000000-0000-0000-0000-000000000199 MMUB: 10000000-0000-0000-0000-000000000199 ==> /proc/2732/status <== Name: init Umask: 0022 State: S (sleeping) Tgid: 2732 Ngid: 0 Pid: 2732 PPid: 1 TracerPid: 0 Uid: 0 0 0 0 Gid: 0 0 0 0 FDSize: 64 Groups: NStgid: 2732 1 NSpid: 2732 1 NSpgid: 2732 1 NSsid: 2732 1 envID: 165 VPid: 1 VmPeak: 19296 kB VmSize: 19284 kB VmLck: 0 kB VmPin: 0 kB VmHWM: 2332 kB VmRSS: 208 kB RssAnon: 100 kB RssFile: 108 kB RssShmem: 0 kB VmData: 200 kB VmStk: 132 kB VmExe: 140 kB VmLib: 2356 kB VmPTE: 60 kB VmSwap: 144 kB Threads: 1 SigQ: 0/30936 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000000000 SigIgn: 0000000000001000 SigCgt: 00000001a0016623 SigSvd: 0000000000000000 CapInh: 0000000000000000 CapPrm: 0000001fffffffff CapEff: 0000001fffffffff CapBnd: 0000001fffffffff CapAmb: 0000000000000000 NoNewPrivs: 0 Seccomp: 0 Speculation_Store_Bypass: not vulnerable Cpus_allowed: 3 Cpus_allowed_list: 0-1 Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001 Mems_allowed_list: 0 voluntary_ctxt_switches: 81020 nonvoluntary_ctxt_switches: 1439 TaskUB: 165 MMUB: 165
Can you please report this upstream? Unfortunately, I do not think I have the means to diagnose this issue.
(In reply to Mukundan Ragavan from comment #3) > Can you please report this upstream? https://github.com/hishamhm/htop/issues/992 ("natoscott" there is me) > Unfortunately, I do not think I have > the means to diagnose this issue. I'll keep digging into it & post an update here.
| here's centos7, note example container id's: 165 and 10000000-0000-0000-0000-000000000199 htop is definitely not going to handle the latter format - it's looking for an unsigned integer. However, the "165" it should have detected correctly. This is the code parsing the proc stat file... #ifdef HAVE_OPENVZ static void LinuxProcessList_readOpenVZData(LinuxProcess* process, const char* dirname, const char* name) { if ( (access("/proc/vz", R_OK) != 0)) { process->vpid = process->super.pid; process->ctid = 0; return; } char filename[MAX_NAME+1]; xSnprintf(filename, MAX_NAME, "%s/%s/stat", dirname, name); FILE* file = fopen(filename, "r"); if (!file) return; (void) fscanf(file, "%*32u %*32s %*1c %*32u %*32u %*32u %*32u %*32u %*32u %*32u " "%*32u %*32u %*32u %*32u %*32u %*32u %*32u %*32u " "%*32u %*32u %*32u %*32u %*32u %*32u %*32u %*32u " "%*32u %*32u %*32u %*32u %*32u %*32u %*32u %*32u " "%*32u %*32u %*32u %*32u %*32u %*32u %*32u %*32u " "%*32u %*32u %*32u %*32u %*32u %*32u %*32u " "%*32u %*32u %32u %32u", &process->vpid, &process->ctid); fclose(file); return; } #endif ... couple questions: - do you have a readable /proc/vz file or directory? if not, it will trip that short-circuit at the top and container IDs will always be zero (like you see) - it looks like it skips the first 51 fields in the stat file and then picks out two unsigned integers - the second is the CTID you seek - by my calculation that should have found "165" from one of your examples - can you check my math there though? Thanks.
>- do you have a readable /proc/vz file or directory? yes. >| here's centos7, note example container id's: 165 and 10000000-0000-0000-0000-000000000199 > >htop is definitely not going to handle the latter format - it's looking for an unsigned integer. Both are legal and operational openvz7 CTIDs! >- it looks like it skips the first 51 fields in the stat file and then picks out two unsigned integers - the second is the CTID you seek - by my calculation that should have found "165" from one of your examples - can you check my math there though? This looks like the bug. According to wc /proc/*/stat contain 53 words on rhel6/openvz6, but contain 61 words on centos7/openvz7. Better to count from the end not the beginning, or better yet extract envID from /proc/*/status (see examples in comment 2). rhel6/openvz6 wc: # p='8308';s=/proc/$p/stat;wc $s;head $s;cat /etc/redhat-release 1 53 292 /proc/8308/stat 8308 (init) S 1 8308 8308 0 -1 4202752 832 158620024 32 1000 145 424 151501 52719 20 0 1 0 6781 19697664 197 18446744073709551615 94308086190080 94308086330580 140721254222176 140721254221256 140083900077699 0 0 4096 536962595 18446744071580818889 0 0 17 0 0 0 19 0 0 0 0 0 0 0 1 166 166 166 Red Hat Enterprise Linux Server release 6.5 (Santiago) centos7/openvz7 wc: # p='{2547,2732}';s=/proc/$p/stat;eval wc $s;eval head $s;cat /etc/redhat-release 1 61 511 /proc/2547/stat 1 61 404 /proc/2732/stat 2 122 915 total ==> /proc/2547/stat <== 2547 (init) S 1 2547 2547 0 -1 1077944576 413 100061755 15 64418 229 748 13529252 2483803 20 0 1 0 5216 19746816 108 18446744073709551615 94398394626048 94398394766548 140720697690544 140720697689624 140556359173763 0 0 4096 536962595 18446744072330174341 0 0 17 0 0 0 39 0 0 94398396865848 94398396871408 94398405701632 140720697692061 140720697692076 140720697692076 140720697692141 0 0 0 0 0 0 1 10000000-0000-0000-0000-000000000199 10000000-0000-0000-0000-000000000199 10000000-0000-0000-0000-000000000199 ==> /proc/2732/stat <== 2732 (init) S 1 2732 2732 0 -1 1077944576 421 60749360 8 1140 139 478 132629 59414 20 0 1 0 5534 19746816 52 18446744073709551615 94109182414848 94109182555348 140728559531520 140728559530600 139829054359171 0 0 4096 536962595 18446744072330174341 0 0 17 0 0 0 48 0 0 94109184654648 94109184660208 94109187067904 140728559538110 140728559538125 140728559538125 140728559538157 0 0 0 0 0 0 1 165 165 165 CentOS Linux release 7.8.2003 (Core)
(In reply to gregrwm from comment #6) > >- do you have a readable /proc/vz file or directory? > > yes. > > > >| here's centos7, note example container id's: 165 and 10000000-0000-0000-0000-000000000199 > > > >htop is definitely not going to handle the latter format - it's looking for an unsigned integer. > > Both are legal and operational openvz7 CTIDs! Is openvz available in Centos / Fedora? AIUI there's a special kernel needed, so I'm guessing not. > This looks like the bug. According to wc /proc/*/stat contain 53 words on > rhel6/openvz6, but contain 61 words on centos7/openvz7. wc may be counting "10000000-0000-0000-0000-000000000199" as multiple (5) words? Probably best if discussion is shifted to the upstream htop issue tracker for more visibility with other developers with OpenVZ setups. Thanks.
>Is openvz available in Centos / Fedora? AIUI there's a special kernel needed, so I'm guessing not. openvz.org >> This looks like the bug. According to wc /proc/*/stat contain 53 words on rhel6/openvz6, but contain 61 words on centos7/openvz7. > >wc may be counting "10000000-0000-0000-0000-000000000199" as multiple (5) words? on rhel6/openvz6 wc counted 53 words in /proc/8308/stat, but on centos7/openvz7 wc counted 61 words in both /proc/2732/stat and /proc/2547/stat (see wc output in comment 6), so clearly it counted all three occurrences of '166' and all three occurrences of '10000000-0000-0000-0000-000000000199' as single words. >Probably best if discussion is shifted to the upstream htop issue tracker for more visibility with other developers with OpenVZ setups. ok...not clear where tho. Want to open something and drop a pointer here?
Please open an upstream issue (htop-dev/htop) and someone with an OpenVZ setup may be able to help. Any upstream fix will no doubt flow to Fedora's htop over time. I'll close this BZ out for now though since a/ noone here is able to help, and b/ OpenVZ is not supported in mainline Linux kernels (and as a result is not supported in Fedora either).