[[!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 too bad the proc server has pid 0 top & co won't show it ## IRC, OFTC, #debian-hurd, 2012-09-18 youpi: did you see https://enc.com.au/2012/09/careful-with-pids/' ? nope ## IRC, OFTC, #debian-hurd, 2013-06-23 I've got this idea about the pid 1 issue you mentioned can't we just make init pid 1? I mean the mapping is rather arbitrary, we could make our init pid 2 or something and start sysvs init as pid 1 not totally sure it is that arbitrary up to the first 4-5 pids y is that? at least i see in hurd's code that /hurd/init is assumed as pid=1 hurds init that has to stick around for the fs translator sync? hurd's init does the basic server startup iirc it also takes care of shutdown/reboot that's what I meant and if it wouldn't have to stick around for the translator sync it could just exec sysvinit I just think it's easier to patch hurd than to remove the assumption that init is pid 1 from sysvinit