The proc server (or, process server) implements some aspects of Unix processes.

It is stated by /hurd/init.

"Unusual" PIDs

IRC, freenode, #hurd, 2012-08-10

<braunr> too bad the proc server has pid 0
<braunr> top & co won't show it

IRC, OFTC, #debian-hurd, 2012-09-18

<pinotree> youpi: did you see
  https://enc.com.au/2012/09/careful-with-pids/'
<pinotree> ?
<youpi> nope

IRC, OFTC, #debian-hurd, 2013-06-23

<teythoon> I've got this idea about the pid 1 issue you mentioned
<teythoon> can't we just make init pid 1?
<teythoon> I mean the mapping is rather arbitrary, we could make our init
  pid 2 or something and start sysvs init as pid 1
<pinotree> not totally sure it is that arbitrary up to the first 4-5 pids
<teythoon> y is that?
<pinotree> at least i see in hurd's code that /hurd/init is assumed as
  pid=1
<teythoon> hurds init that has to stick around for the fs translator sync?
<pinotree> hurd's init does the basic server startup
<pinotree> iirc it also takes care of shutdown/reboot
<teythoon> that's what I meant
<teythoon> and if it wouldn't have to stick around for the translator sync
  it could just exec sysvinit
<teythoon> I just think it's easier to patch hurd than to remove the
  assumption that init is pid 1 from sysvinit

IRC, freenode, #hurd, 2013-09-13

<braunr> teythoon: also, as a feature request, i'd like the proc server not
  to have pid 0, if you have any time to do that
<braunr> so it appears in top and friends
<teythoon> braunr: noted, that should be easy
<teythoon> not using 0 is probably a good thing, many things use pid 0 as
  something special

IRC, freenode, #hurd, 2013-09-25

<braunr> so nice to finally see proc in top :)

Process Discovery

IRC, freenode, #hurd, 2013-08-26

< teythoon> somewhat related, I do not like the way the proc server just
  creates processes for new mach tasks it discovers
< teythoon> that does not play well with subhurds for example
< braunr> teythoon: i agree with you on proc process-to-task mapping
< braunr> that's something i intend to completely rework on propel
< braunr> in a way similar to how pid namespaces work on linux

PID "Races"

IRC, freenode, #hurd, 2014-01-26

<quotemstr> Does Hurd have anything that generally solves PID races?
<youpi> what kind of race are you thinking about?
<youpi> I'm not sure, but I guess keeping a reference to a task port will
  prevent the proc server from recycling the corresponding pid
<quotemstr> Yep.
<quotemstr> How does the Hurd avoid the obvious denial-of-service attack
  that results?
<youpi> well quotas would probably be enough
<youpi> that's not a new issue :)
<quotemstr> Fair enough.
<quotemstr> Returning to the POSIX-y world after a few year stint over in
  NT-land, it's infuriating that it's still not possible to write a
  reliable killall(1) under Linux or the BSDs.
<quotemstr> I'm glad Hurd solves the problem. :-)
<braunr> but it doesn't
<braunr> how can you write a reliable killall ?
<youpi> so keeping a reference to the task port is not enough?
<braunr> i'm not sure
<braunr> first i'd like quotemstr to clearly define the reliability problem
  of killall
<quotemstr> braunr: The possibility that a PID might be used between the
  time you decide to kill it and the time you actually kill it.
<braunr> well, it would have to wrap around for that
<quotemstr> braunr: So? It's possible.
<braunr> i guess that's what you refer to
<braunr> ok
<braunr> well yes, it's possible to easily create a routine that atomically
  increases the number of references on a task/process when looking it up
<braunr> preventing its removal from the list of processes reported by the
  proc server
<quotemstr> Like OpenProcess? :-) Would this reference count be
  automatically decremented if the task owning the reference is killed?
<braunr> it would clearly not be a "posixy killall" then, but i suppose we
  don't care about that at all
<braunr> no
<quotemstr> Oh.
<braunr> destroying an object doesn't remove its references 
<quotemstr> So it's possible to leak the reference and prevent reuse of
  that PID forever.
<braunr> hardly
<braunr> for that, killall would have to run a long time
<quotemstr> braunr: No, I'm talking about our hypothetical killall itself
  being killed after taking out a reference on another process, but before
  releasing it
<braunr> but a malicious killall could
<braunr> when a task is destroyed, its capability space is destroyed too
<braunr> removing all the references it previously had
<quotemstr> Ah, I see.
<braunr> the leaks we have occur in servers
<braunr> which sometimes act as clients to other servers
<braunr> and run forever

Crashes due to rpctrace

IRC, freenode, #hurd, 2014-02-18

<braunr> something is wrong in the proc server
<braunr> rpctrace is often causing it to crash ..