Community
Participate
Working Groups
Created attachment 191027 [details] Screenshot with the problem CQ:WIND00259395 On an RSE connection against a Linux TCF agent, Proceses with "/0" in the names are reported with a "0" name in the RSE Processes subsystem. See attached screenshot
I don't see this coming back in the protocol. This must be something the RSE integration is doing.
I'll take a look.
The problem is in the TCFProcessResource#getName(): ... int i = s.lastIndexOf('/'); int j = s.lastIndexOf('\\'); if (j > i) i = j; if (i > 0) s = s.substring(i + 1); ... The code is perfectly fine for normal processes but will return 0 for, say, softirq/0. I am not sure how to fix it properly, because you can create a file named "0" inside a directory "softirq" and then the returned result will be correct.
Linux "top" and "ps" know the difference between the process name ("foo/0") and the absolute path pointing to the image (/path/to/foo). Does the TCF protocol API give you both fields separately? Then it's easy to fix this. If all you can get from TCF "/path/to/foo/0" it looks like it's a limitation in the TCF protocol API.
I think TCF only returns one(Eugene, Felix, correct me if I am wrong), but I'll double check.
I don't know how "top" and "ps" know the difference. Processes and SysMonitor together provide pretty much all available info. If "top" can do it, we should be able to do it too.
I took a look at the procps sources and this is what I found. Top's proc_t structure has entries for both cmdline and cmd, the latter is the basename of executable file in call to exec(2). The first one is obtained from the /proc/<PID>/cmdline. For kernel threads like ksoftirqd/0 it is empty. The cmd is the "name" field which is read from the /proc/<PID>/status and it is "ksoftirqd/0" in this case.
Eugene should we reassign this to TCF : Agent component based on Anna's findings?
I need to investigate. Changing "Assigned To" to myself.
"name" field of /proc/<PID>/status is same as "comm" field of /proc/<PID>/stat and same as "File" field of SysMonitor service context. Since the field already contains what we want, I have deleted the code that removes path prefix. Fixed.
