How to implement System.Diagnostics.Process on FreeBSD?

[ghuntley]

This issue is to discuss how we can implement System.Diagnostics.Process on FreeBSD which does not have procfs by enabled by default as it should be considered deprecated.

Reference Material

• Implement basic System.Diagnostics.Process.Modules support on Linux dotnet/corefx#2188

• The System.Diagnostics.Process specification on MSDN.

• The FreeBSD process information implementation within Mono (LGPL)

• The FreeBSD process information implementation within IO.JS (MIT)

• https://www.freebsd.org/cgi/man.cgi?procstat and https://www.freebsd.org/cgi/man.cgi?sysctl(3)

       KERN_PROC
   Return selected information about specific running processes.
  
   For the following names, an array of struct kinfo_proc structures
   is returned, whose size depends on the current number of such
   objects in the system.
  
     Third level name      Fourth level is:
     KERN_PROC_ALL         None
     KERN_PROC_PID         A process ID
     KERN_PROC_PGRP        A process group
     KERN_PROC_TTY         A tty device
     KERN_PROC_UID         A user ID
     KERN_PROC_RUID        A real user ID
  
   If the third level name is KERN_PROC_ARGS then the command line
   argument array is returned in a flattened form, i.e., zero-termi-
   nated arguments follow each other.  The total size of array is
   returned.  It is also possible for a process to set its own
   process title this way.  If the third level name is
   KERN_PROC_PATHNAME, the path of the process' text file is stored.
   For KERN_PROC_PATHNAME, a process ID of -1 implies the current
   process.
  
     Third level name      Fourth level is:
     KERN_PROC_ARGS        A process ID
     KERN_PROC_PATHNAME        A process ID
  

/cc: @janhenke @saper @jasonwilliams200OK @josteink

[stephentoub]

The FreeBSD process information implementation within Mono

Thanks for the info, but please be careful linking to such code... to my knowledge, code in that area of Mono is under a license not compatible with MIT.

[meebey]

@stephentoub that statement isn't correct. the MIT license is liberal enough that combined work of LGPLed code and MIT code effectively becomes LGPL.

[stephentoub]

What I meant is that is that this corefx codebase is covered by the MIT license; you couldn't take code from areas of the Mono codebase covered by LGPL and just commit it to corefx.

[meebey]

Technically you can, but the .NET Foundation will probably object such contribution, yes :)

[stephentoub]

Which means you can't 😉 It will not be merged.

[saper]

I wrote this code, you can treat it as public domain, it is no different from the manual page examples.

I hope it helps :)

[ghuntley]

Tip-off from jasonwilliams200OK:

AFAIK, io.js team had similar challenges with FreeBSD process management.

https://github.com/nodejs/io.js/blob/master/deps/uv/src/unix/freebsd.c (MIT)

[ghost]

@sokket, is System.Diagnostics.Process anywhere on the shim radar? :)
( hopefully not, but ) I think this one is going to be bit more challenging than dotnet/corefx#3471.

[jonmill]

Sorry for the late response, I was on vacation the last few days...

@jasonwilliams200OK Yup, my goal is to get all the native calls shim'd, System.Diagnostics.Process included :). Is this specific one blocking you guys?

[ghost]

@sokket, welcome back! :D
Yup this is one of those assemblies, which are not building. Besides that there are some types which would probably require special .FreeBSD.cs partial classes:

• System.Diagnostics.ProcessManager
• System.Diagnostics.ThreadInfo
• System.IO.FileSystemWatcher
• System.Net.SocketAddress (alright, this one was added recently)

For the rest of the congress of assemblies, which are successfully building, we are unable to test due to dotnet/buildtools#300 (and maybe other unknown factors too: https://github.com/dotnet/coreclr/issues/1633#issuecomment-143669303).

[jonmill]

I did an initial investigation into FileSystemWatcher and wrote about it in #14716, but the tldr; is that the FreeBSD version would work very differently from the OSX and Linux implementations today. We have some options for how to mitigate that written up in the bug.

I'm currently working on shim'ing the ProcessInfo and ThreadInfo native calls over, but it looks like FreeBSD does not have the OSX system calls or ProcFS like on Linux. My refactor should make it simple for new platforms (such as FreeBSD 😄) to be brought up and working, as long as someone knows the correct native calls for that platform. If anyone on this thread knows the correct calls for retrieving process information, shoot me an email and (if they're trivial to add) I can add them to the PAL layer with my current pack

[saper]

I have written the Mono implementation in mono/mono#1864. Feel free to use that (I have added a comment to dedicate this to public domain). Actually you should be able to use a (superior in my opinion) sysctl interface also on MacOSX (with some little changes).

Mono currently does not even require /proc to be mounted on FreeBSD now and the use of /proc is discouraged on this system.

[jonmill]

I had to roll back some of the refactoring changes so I won't be able to get this into my current pack, unfortunately :(

[josteink]

With the task of moving to shims done, should this issue too be closed?

[Priya91]

Closing this issue, given that mono implementations can be used now, and also shim work is done. Please open new issue with current data on Freebsd support if required.