htop recognizes most user-space processes as kernel threads (!)

[VittGam]

Hello,

In order to view most user-space processes in htop, I need to show kernel threads in the setup.

There is obviously something wrong with this.

Also, command lines of those badly-recognized processes do not show up (because they're seen as kernel threads...).

I'm using BB r42853, but if I remember well this is happening since OpenWrt started using procd as init (I thought there was something wrong with my setup at the time so I didn't report it...).

This is a screen after enabling colors and tree too.

Regards,
Vittorio G

[ffainelli]

The htop output looks just fine to me, all processes listed as childs of kthreadd are indeed kernel threads, and every other process is a child of procd, which is our init system.

[VittGam]

This is how the output should look, with the user-space processes being recognized correctly (blue and not green...)

But it is not just a problem of colors. If you disable visualization of kernel threads in OpenWrt, the user-space processes will disappear too.

[champtar]

http://stackoverflow.com/questions/12213445/identifying-kernel-threads
for me it look like a procd bug/feature

process with old init file are fine
process with new init file (USE_PROCD=1) are kernel threads for htop

@nbd168, @jow-, @blogic, any insight on procd

[champtar]

https://github.com/hishamhm/htop/blob/0e8a02367ec7ca8f52b10de70938dfd07faed3ab/Process.h#L33

[champtar]

If pgrp == 0 (process group), htop considers the thread a kernel thread. I don't know if procd not setting pgrp is a real bug, but it seems to be the only init not doing it (in AA, init pgrp is 1, on BB, procd pgrp is 0, on fedora 20 systemd pgrp is 1, ...)

[hnyman]

Is there any comment from the procd developers?
It seems to me that procd is the one "init" program differing from the usual behaviour here, causing misdetection for htop here.

I patched procd in my router to set its own process group to 1 (or actually its process id =1), after which htop showed the previously misdetected non-kernel processes correctly (see below). Earlier only those process that had set their own process group, were detected as non-kernel processes.

--- a/procd.c
+++ b/procd.c
@@ -62,6 +62,7 @@
            return usage(argv[0]);
        }
    }
+   setpgid(0,0);
    uloop_init();
    procd_signal();
    trigger_init();

I am not sure if that is the optimal way to change procd, but it seems to work.

After that htop shows also the previously missing non-kernel processes, as their process group is now non-zero:

  CPU[|                                                    0.9%]     Tasks: 18, 10 thr; 1 running
  Mem[|||||||||||||||||||||||||||||||||||||             20/60MB]     Load average: 0.23 0.19 0.08
  Swp[                                                    0/0MB]     Uptime: 00:02:22

 PGRP   PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
    1     1 root       20   0  1400   636   436 S  0.0  1.0  0:04.50 /sbin/procd
    1  1866 root       20   0  1372   476   400 S  0.0  0.8  0:00.17 `- /usr/sbin/ntpd -n -p 0.openwrt.pool.ntp.org -p 1.openwrt.pool.n
 1816  1816 root       20   0 26716  3436  2924 S  0.0  5.6  0:05.53 `- /usr/sbin/collectd
 1816  1827 root       20   0 26716  3436  2924 S  0.0  5.6  0:00.00 |  `- /usr/sbin/collectd
 1816  1826 root       20   0 26716  3436  2924 S  0.0  5.6  0:00.07 |  `- /usr/sbin/collectd
 1816  1825 root       20   0 26716  3436  2924 S  0.0  5.6  0:00.01 |  `- /usr/sbin/collectd
 1816  1824 root       20   0 26716  3436  2924 S  0.0  5.6  0:00.00 |  `- /usr/sbin/collectd
 1816  1823 root       20   0 26716  3436  2924 S  0.0  5.6  0:05.40 |  `- /usr/sbin/collectd
 1816  1822 root       20   0 26716  3436  2924 S  0.0  5.6  0:00.01 |  `- /usr/sbin/collectd
 1816  1821 root       20   0 26716  3436  2924 S  0.0  5.6  0:00.01 |  `- /usr/sbin/collectd
 1816  1820 root       20   0 26716  3436  2924 S  0.0  5.6  0:00.01 |  `- /usr/sbin/collectd
 1816  1819 root       20   0 26716  3436  2924 S  0.0  5.6  0:00.01 |  `- /usr/sbin/collectd
 1816  1818 root       20   0 26716  3436  2924 S  0.0  5.6  0:00.01 |  `- /usr/sbin/collectd
    1  1749 nobody     20   0   924   484   388 S  0.0  0.8  0:00.04 `- /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k
 1737  1737 root       20   0  1764   484   308 S  0.0  0.8  0:00.01 `- /usr/sbin/hostapd -P /var/run/wifi-phy0.pid -B /var/run/hostapd
 1683  1683 root       20   0  1764   480   304 S  0.0  0.8  0:00.02 `- /usr/sbin/hostapd -P /var/run/wifi-phy1.pid -B /var/run/hostapd
 1650  1650 root       20   0  2956   516   332 S  0.0  0.8  0:00.00 `- /usr/sbin/vsftpd
    1  1482 root       20   0  3464  1324  1052 S  0.0  2.2  0:00.31 `- /usr/sbin/uhttpd -f -h /www -r OpenWrt2 -x /cgi-bin -u /ubus -t
    1  1155 root       20   0  1152   424   348 S  0.0  0.7  0:00.07 `- /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300
 1976  1976 root       20   0  1216   540   396 S  0.0  0.9  0:01.42 |  `- /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 30
 1981  1981 root       20   0  1372   456   376 S  0.0  0.7  0:00.03 |     `- -ash
 1986  1986 root       20   0  1372   760   536 R  1.4  1.2  0:01.54 |        `- htop
    1  1111 root       20   0  1160   528   372 S  0.0  0.9  0:00.10 `- /usr/sbin/odhcpd
    1  1076 root       20   0  1552   720   500 S  0.0  1.2  0:00.18 `- /sbin/netifd
    1  1456 root       20   0   816   356   276 S  0.0  0.6  0:00.06 |  `- odhcp6c -s /lib/netifd/dhcpv6.script -t120 br-lan
    1  1042 root       20   0  1088   468   272 S  0.0  0.8  0:00.07 `- /sbin/logd -S 64
    1   451 root       20   0   772   216   160 S  0.0  0.4  0:00.00 `- /sbin/askfirst ttyS0 /bin/ash --login
    1   408 root       20   0   896   288   212 S  0.0  0.5  0:00.04 `- /sbin/ubusd

[blogic]

Hi,

2nd report of that problem in 3 days. i am working on a slightly
different fix that uses setsid(), i will mail you a patch for testing
the next couple of days.

John

On 03/11/2014 19:07, hnyman wrote:

Is there any comment from the procd developers? It seems to me that
procd is the one "init" program differing from the usual behaviour
here, causing misdetection for htop here.

I patched procd in my router to set its own process group to 1 (or
actually its process id =1), after which htop showed the
previously misdetected non-kernel processes correctly (see below).
Earlier only those process that had set their own process group,
were detected as non-kernel processes.

|--- a/procd.c +++ b/procd.c @@ -62,6 +62,7 @@ return
usage(argv[0]); } } + setpgid(0,0); uloop_init();
procd_signal(); trigger_init(); |

I am not sure if that is the optimal way to change procd, but it
seems to work.

After that htop shows also the previously missing non-kernel
processes, as their process group is now non-zero:

| CPU[| 0.9%]
Tasks: 18, 10 thr; 1 running
Mem[||||||||||||||||||||||||||||||||||||| 20/60MB]
Load average: 0.23 0.19 0.08 Swp[
0/0MB] Uptime: 00:02:22

PGRP PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+
Command 1 1 root 20 0 1400 636 436 S 0.0 1.0
0:04.50 /sbin/procd 1 1866 root 20 0 1372 476 400 S
0.0 0.8 0:00.17 - /usr/sbin/ntpd -n -p 0.openwrt.pool.ntp.org -p 1.openwrt.pool.n 1816 1816 root 20 0 26716 3436 2924 S 0.0 5.6 0:05.53- /usr/sbin/collectd 1816 1827 root 20
0 26716 3436 2924 S 0.0 5.6 0:00.00 | - /usr/sbin/collectd 1816 1826 root 20 0 26716 3436 2924 S 0.0 5.6 0:00.07 |- /usr/sbin/collectd 1816 1825 root 20 0 26716 3436
2924 S 0.0 5.6 0:00.01 | - /usr/sbin/collectd 1816 1824 root 20 0 26716 3436 2924 S 0.0 5.6 0:00.00 |-
/usr/sbin/collectd 1816 1823 root 20 0 26716 3436 2924 S
0.0 5.6 0:05.40 | - /usr/sbin/collectd 1816 1822 root 20 0 26716 3436 2924 S 0.0 5.6 0:00.01 |- /usr/sbin/collectd
1816 1821 root 20 0 26716 3436 2924 S 0.0 5.6 0:00.01
| - /usr/sbin/collectd 1816 1820 root 20 0 26716 3436 2924 S 0.0 5.6 0:00.01 |- /usr/sbin/collectd 1816 1819 root
20 0 26716 3436 2924 S 0.0 5.6 0:00.01 | - /usr/sbin/collectd 1816 1818 root 20 0 26716 3436 2924 S 0.0 5.6 0:00.01 |- /usr/sbin/collectd 1 1749 nobody 20
0 924 484 388 S 0.0 0.8 0:00.04 - /usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf -k 1737 1737 root 20 0 1764 484 308 S 0.0 0.8 0:00.01- /usr/sbin/hostapd -P
/var/run/wifi-phy0.pid -B /var/run/hostapd 1683 1683 root 20
0 1764 480 304 S 0.0 0.8 0:00.02 - /usr/sbin/hostapd -P /var/run/wifi-phy1.pid -B /var/run/hostapd 1650 1650 root 20 0 2956 516 332 S 0.0 0.8 0:00.00- /usr/sbin/vsftpd 1
1482 root 20 0 3464 1324 1052 S 0.0 2.2 0:00.31 - /usr/sbin/uhttpd -f -h /www -r OpenWrt2 -x /cgi-bin -u /ubus -t 1 1155 root 20 0 1152 424 348 S 0.0 0.7 0:00.07-
/usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 300 1976
1976 root 20 0 1216 540 396 S 0.0 0.9 0:01.42 | - /usr/sbin/dropbear -F -P /var/run/dropbear.1.pid -p 22 -K 30 1981 1981 root 20 0 1372 456 376 S 0.0 0.7 0:00.03 | - -ash 1986 1986 root 20 0 1372 760 536 R 1.4 1.2
0:01.54 | - htop 1 1111 root 20 0 1160 528 372 S 0.0 0.9 0:00.10- /usr/sbin/odhcpd 1 1076 root 20
0 1552 720 500 S 0.0 1.2 0:00.18 - /sbin/netifd 1 1456 root 20 0 816 356 276 S 0.0 0.6 0:00.06 |-
odhcp6c -s /lib/netifd/dhcpv6.script -t120 br-lan 1 1042 root
20 0 1088 468 272 S 0.0 0.8 0:00.07 - /sbin/logd -S 64 1 451 root 20 0 772 216 160 S 0.0 0.4 0:00.00-
/sbin/askfirst ttyS0 /bin/ash --login 1 408 root 20 0
896 288 212 S 0.0 0.5 0:00.04 `- /sbin/ubusd |

— Reply to this email directly or view it on GitHub
#426 (comment).

[hnyman]

r43193 fixed things for trunk by changing procd to behave better. Its process group is no more 0, so the userspace processes get recognised correctly.

The issue could maybe be closed, as trunk is fixed. BB will get fixed if current procd gets backported there.

[blogic]

On 06/11/2014 23:04, hnyman wrote:

r43193 fixed things for trunk by changing procd to behave better.
Its process group is no more 0, so the userspace processes get
recognised correctly.

The issue could maybe be closed, as trunk is fixed. BB will get
fixed if current procd gets backported there.

i am not sure this was all. i think that we need to also call setsid()
when ever we fork a process instance, worker script and inttab.

John

— Reply to this email directly or view it on GitHub
#426 (comment).