[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

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

It is stated by `/hurd/init`.


# "Unusual" PIDs

[[!tag open_issue_hurd]]


## 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 :)
    <braunr> hm cute, htop layout has become buggy, top just won't start
    <teythoon> braunr: make sure your procfs knows the correct kernel pid
    <teythoon> # showtrans /proc
    <teythoon> /hurd/procfs -c -k 3
    <teythoon> we could have handled this nicer if procfs were integrated
      upstream
    <teythoon> we should probably just update the default
    <braunr> teythoon: mhm
    <braunr> $ fsysopts /proc
    <braunr> /hurd/procfs --stat-mode=444 --fake-self=1
    <braunr> $ showtrans /proc
    <braunr> /hurd/procfs -c
    <pinotree> -c == --stat-mode=444 --fake-self=1
    <braunr> better indeed
    <braunr> teythoon: thanks


## IRC, freenode, #hurd, 2013-10-24

    <gg0> braunr: i'm using your repo and i can't see cpu percentage in htop
      anymore, all zeroes, confirmed?
    <braunr> gg0: no
    <braunr> gg0: you probably need to reset procfs
    <braunr> gg0: settrans /proc /hurd/procfs -c -k 3


# 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