Process.GetProcesses returns truncated 15 char string on Linux

[2E0PGS]

When using Process.GetProcesses() in dotnet core it returns the Process.ProcessName property fine under Windows as expected.

However when ran under Linux (Tested on Ubuntu 17.04) it seems to return process names as 15 char long strings. It truncates the process names to all be 15 char long strings.

My applogies if there is an issue for this somewhere under another repo. I found there was such an issue with the mono framework when doing research prior to submitting this issue: https://bugzilla.xamarin.com/show_bug.cgi?id=32539

[danmoseley]

Thanks for the pointer to the MacOS bug fix. It seems Linux has a similar limit. Here is a process with a 30 character name, only 15 show:

dan@danmose3:~/git/corefx/src/Native$ cat /proc/10725/stat
10725 (123456789012345) S 10116 10725 10115 1025 0 0 0 0 0 0 0 0 0 0 20 0 1 0 17132735 97915326464 204 18446744073709551615 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

This is because /proc/<PID>/stat gets the value from task_struct which is TASK_COMM_LEN chars (sched.h) which is 16 including null.

[danmoseley]

It looks like /proc/<PID>/exe is one way to get the full file name

dan@danmose3:~/git/corefx/src/Native$ ls -l /proc/10725/exe
lrwxrwxrwx 1 dan dan 0 Jan  8 14:38 /proc/10725/exe -> /home/dan/123456789012345678901234567890

[danmoseley]

It looks like we already get the full exe path from this file. We just need to use it a few lines higher up (cropping off the path) instead of the stat entry

https://github.com/dotnet/corefx/blob/e0ba7aa8026280ee3571179cc06431baf1dfaaac/src/System.Diagnostics.Process/src/System/Diagnostics/ProcessManager.Linux.cs#L76-L85

[danmoseley]

@2E0PGS any interest in making this change, with a unit test?

[2E0PGS]

Thanks for pulling out those lines and doing a few basic tests.

I will have a further look at the code base and check what unit tests are in place at the moment.

I will try give it a shot if I get some free time. Otherwise I will let you know if I am too busy to make the change.

[danmoseley]

OK, thanks. As for Mac it seems we do not use /proc/../stat but it would be nice to have a test (need not be you of course)

[danmoseley]

@2E0PGS do you think you might give this a go? Let me know if you need pointers getting set up?

[2E0PGS]

Sorry been very busy. Yes I was just reading the dotnet core wiki for setting up the development environment. Hopefully I can give it a go soon.

[2E0PGS]

I don't quite know know why the solution doesn't pickup the distro specific cs files.

[2E0PGS]

Got a build done, just need to see how I am going to run this inplace of regular dotnet core on the system to check it against my test program.

[danmoseley]

Have you written a unit test? Take a look at existing tests under Systrm.Diagnostics.Process/tests. There are some that launch processes. You could follow the pattern but rename the file to a long name before launching. Or possibly copy "sleep" to a long name version then run it with a large value, read the name, then terminate it and delete it. This assumes all distros have sleep.

[2E0PGS]

Thanks will try that when back home. ⁣Sent from BlueMail ​

…

On 2 Feb 2019, 19:17, at 19:17, Dan Moseley ***@***.***> wrote: Have you written a unit test? Take a look at existing tests under Systrm.Diagnostics.Process/tests. There are some that launch processes. You could follow the pattern but rename the file to a long name before launching. Or possibly copy "sleep" to a long name version then run it with a large value, read the name, then terminate it and delete it. This assumes all distros have sleep. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/dotnet/corefx/issues/34437#issuecomment-459991461

[2E0PGS]

I got this so far: 2E0PGS/corefx@691e55e

Just need to test this on Linux.

[2E0PGS]

OK so implementing those changes: 2E0PGS/corefx@e1e308c

Using my test program the output we had before any of my changes looked like this and it had a name for every process.

Process name: systemd
Process name: kthreadd
Process name: kworker/0:0
Process name: kworker/0:0H

Using the recent commit I linked above the test program has quite a few processes without names.

Process name: systemd
Process name: 
Process name: 
Process name: mate-session
Process name: dbus-daemon

[2E0PGS]

However the names are now longer than 15 chars. We need to investigate why some are blank.