1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
[[!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
|
