open issue documentation: edit and move to FAQ.

IRC, freenode, #hurd, around 2010-09

<pinotree> (also, shouldn't /proc/version say something else than "Linux"?)
<youpi> to make linux tools work, no :/
<youpi> kfreebsd does that too
<pinotree> really?
<youpi> yes
<youpi> (kfreebsd, not freebsd)
<pinotree> does kbsd's one print just "Linux version x.y.z" too, or
  something more eg in a second line?
<pinotree> (as curiosity)
<youpi> % cat /proc/version
<youpi> Linux version 2.6.16 (des@freebsd.org) (gcc version 4.3.5) #4 Sun
  Dec 18 04:30:00 CET 1977
<pinotree> k

IRC, freenode, #hurd, 2013-06-04

<safinaskar> ?@?#@?$?@#???!?!?!?!??!?!?!?! why /proc/version on gnu system
  reports "Linux version 2.6.1 (GNU 0.3...)"?
<braunr> safinaskar: because /proc/version is a linux thing
<braunr> applications using it don't expect to see anything else than linux
  when parsing
<braunr> think of it as your web brower allowing you to set the user-agent
<safinaskar> braunr: yes, i just thought about user-agent, too
<safinaskar> braunr: but freebsd doesn't report it is linux (as well as i
<braunr> their choice
<braunr> we could change it, but frankly, we don't care
<safinaskar> so why "uname" says "GNU" and not "Linux"?
<braunr> uname is posix
<braunr> note that /proc/version also includes GNU and GNU Mach/Hurd
<safinaskar> if some program read the word "Linux" from /proc/version, it
  will assume it is linux. so, i think it is bad idea
<braunr> why ?
<safinaskar> there is no standard /proc across unixen
<braunr> if a program reads /proc/version, it expects to be run on linux
<safinaskar> every unix implement his own /proc
<safinaskar> so, we don't need to create /proc which is fully compatible
  with linux
<braunr> procfs doesn't by default
<safinaskar> instead, we can make /proc, which is partially compatible with
<braunr> debiansets the -c compatibility flag
<braunr> that's what we did
<safinaskar> but /proc/version should really report kernel name and its
<braunr> why ?
<braunr> (and again, it does)
<safinaskar> because this is why /proc/version created
<pinotree> no?
<braunr> on linux, yes
<braunr> pinotree: hm ?
<safinaskar> and /proc/version should not contain the "Linux" word, because
  this is not Linux
<braunr> pinotree: no to what ? :)
<braunr> safinaskar: *sigh*
<braunr> i explained the choice to you
<pinotree> safinaskar: if you are using /proc/version to get the kernel
  name and version, you're doing bad already
<braunr> disagree if you want
<braunr> but there is a point to using the word Linux there
<pinotree> safinaskar: there's the proper aposix api for that, which is
<safinaskar> pinotree: okey. so why we ever implement /proc/version?
<braunr> it's a linux thing
<braunr> they probably wanted more than what the posix api was intended to
<safinaskar> okey, so why we need this linux thing?   there is a lot of
  linux thing which is useful in hurd.  but not this thing.   because this
  is not linux.    if we support /proc/version, we should not write "Linux"
  to it
<pinotree> and even on freebsd their linprocfs (mounted on /proc) is not
  mounted by default
<braunr> 10:37 < braunr> applications using it don't expect to see anything
  else than linux when parsing
<braunr> 10:37 < braunr> think of it as your web brower allowing you to set
  the user-agent
<braunr> safinaskar: the answer hasn't changed
<safinaskar> pinotree: but they don't export /proc/version with "Linux"
  word in it anyway
<pinotree> safinaskar: they do
<safinaskar> pinotree: ??? their /proc/version contain Linux?
<pinotree> Linux version 2.6.16 (des@freebsd.org) (gcc version 4.6.3) #4
  Sun Dec 18 04:30:00 CET 1977
<kilobug> safinaskar: it's like all web browsers reporting "mozilla" in
  their UA, it may be silly, but it's how it is for
  compatibility/historical reasons, and it's just not worth the trouble of
  changing it
<pinotree> that's on a debian gnu/kfreebsd machine
<pinotree> and on a freebsd machine it is the same
<braunr> safinaskar: you should understand that parsing this string allows
  correctly walking the rest of the /proc tree
<pinotree> and given such filesystem on freebsd is called "linprocfs", you
  can already have a guess what it is for
<kilobug> safinaskar: saying "Linux version 2.6.1" just means "I'm
  compatible with Linux 2.6.1 interfaces", like saying "Mozilla/5.0 (like
  Gecko)" in the UA means "I'm a modern browser"
<safinaskar> so, is there really a lot of programs which expect "Linux"
  word in /proc/version even on non-linux platforms?
<braunr> no
<braunr> but when they do, they do


IRC, freenode, #hurd, around 2010-09

<youpi> jkoenig: is it not possible to provide a /proc/self which points at
  the client's pid?
<pinotree> looks like he did 'self' too, see rootdir_entries[] in rootdir.c
<youpi> but it doesn't point at self
<antrik> youpi: there is no way to provide /proc/self, because the server
  doesn't know the identity of the client
<youpi> :/
<antrik> youpi: using the existing mechanisms, we would need another magic
  lookup type
<antrik> an alternative idea I discussed with cfhammer once would be for
  the client to voluntarily provide it's identity to the server... but that
  would be a rather fundamental change that requires careful consideration
<antrik> also, object migration could be used, so the implementation would
  be provided by the server, but the execution would happen in the
  client... but that's even more involved :-)
<youpi> but we've seen how much that'd help with a lot of other stuff
<antrik> I'm not sure whether we discussed this on the ML at some point, or
  only on IRC
<youpi> it "just" needs to be commited :)
<antrik> in either case, it can't hurt to bring this up again :-)

discussion, IRC, freenode, #hurd, 2013-09-07. Look at [glibc]/hurd/lookup-retry.c for how FS RETRY MAGICAL lookups work.

root group

IRC, freenode, #hurd, around October 2010

<pinotree> the only glitch is that files/dirs have the right user as
  owner, but always with root group

/proc/[PID]/stat being 400 and not 444, and some more

IRC, freenode, #hurd, 2011-03-27

<pochu> is there a reason for /proc/$pid/stat to be 400 and not 444 like on
<pochu> there is an option to procfs to make it 444 like Linux
<pochu> jkoenig: ^
<jkoenig> pochu, hi
<jkoenig> /proc/$pid/stat reveals information which is not usually
  available on Hurd
<jkoenig> so I made it 400 by default to avoid leaking anything
<pochu> is there a security risk in providing that info?
<jkoenig> probably not so much, but it seemed like it's not really a
  descision procfs should make
<jkoenig> I'm not sure which information we're speaking about, though, I
  just remember the abstract reason.
<pochu> things like the pid, the memory, the priority, the state...
<pochu> sounds safe to expose
<jkoenig> also it's 0444 by default in "compatible" mode
<jkoenig> (which is necessary for the linux tools to work well)
<pochu> yeah I saw that :)
<pochu> my question is, should we change it to 0444 by default? if there
  are no security risks and this improves compatibility, sounds like a good
  thing to me
<pochu> we're already 'leaking' part of that info through e.g. ps
<jkoenig> I think /proc should be translated by /hurd/procfs --compatible
  by default (I'm not sure whether it's already the case)
<jkoenig> also I'm not sure why hurd-ps is setuid root, rather than the
  proc server being less paranoid, but maybe I'm missing something.
<pochu> jkoenig: it's not, at least not on Debian
<pochu> youpi: hi, what do you think about starting procfs with
  --compatible by default?
<pochu> youpi: or changing /proc/$pid/stat to 0444 like on Linux
  (--compatible does that among a few other things)
<youpi> I guess you need it for something?
<pochu> I'm porting libgtop :)
<youpi> k
<pochu> though I still think we should do this in procfs itself
<youpi> ymmv
<jkoenig> pochu, youpi, --compatible is also needed because mach's high
  reported sysconf(_SC_CLK_TCK) makes some integers overflow (IIRC)
<youpi> agreed
<jkoenig> luckily, tools which use procfs usually try to detect the value
  /proc uses rather than rely on CLK_TCK
<jkoenig> (so we can choose whatever reasonable value we want)

IRC, freenode, #hurd, 2011-03-28

<antrik> jkoenig: does procfs expose any information that is not available
  to everyone through the proc server?...
<antrik> also, why is --compatible not the default; or rather, why is there
  even another mode? the whole point of procfs is compatibility...
<jkoenig> antrik, yes, through the <pid>/environ and (as mentionned above)
  <pid>/stat files, but I've been careful to make these files readable only
  to the process owner
<jkoenig> --compatible is not the default because it relaxes this paranoia
  wrt. the stat file, and does not conform to the specification with regard
  to clock tick counters
<antrik> what specification?
<jkoenig> the linux proc(5) manpage
<jkoenig> which says clock tick counters are in units of
<antrik> so you are saying that there is some information that the Hurd
  proc server doesn't expose to unprivileged processes, but linux /proc
<jkoenig> yes
<antrik> that's odd. I wonder what the reasoning behind that could be
<antrik> but this information is available through Hurd ps?
<antrik> BTW, what exactly is _SC_CLK_TCK supposed to be?
<pinotree> jkoenig: hm, just tried with two random processes on linux
  (2.6.32), and enrivon is 400
<pinotree> (which makes sense, as you could have sensible informations eg
  in http_proxy or other envvars)
<jkoenig> antrik, CLK_TCK is similar to HZ (maybe clock resolution instead
  of time slices ?)
<jkoenig> sysconf(3) says "The number of clock ticks per second."
<jkoenig> antrik, I don't remember precisely what information this was, but
  ps-hurd is setuid root.
<jkoenig> anyway, if you run procfs --compatible as a user and try to read
  foo/1/stat, the result is an I/O error, which is the result of the proc
  server denying access.
<antrik> but Linux /proc acutally uses HZ as the unit IIRC? or is
  _SC_CLK_TCK=HZ on Linux?...
<jkoenig> I expect they're equal.
<jkoenig> in practice procps uses heuristics to guess what value /proc uses
  (for compatibility purposes with older kernels)
<jkoenig> I don't think HZ is POSIX, while _SC_CLK_TCK is specifies as the
  unit for (at least) the values returned by times()
<jkoenig> s/specifies/specified/
<jkoenig> antrik, some the information is fetched directly from mach by
  libps, and understandably, the proc server does not give the task port to
  anyone who asks.
<antrik> well, as long as the information is exposed through ps, there is
  no point in hiding it in procfs...
<antrik> and I'm aware of the crazy guessing in libproc... I was actually
  mentoring the previous procfs implementation
<antrik> (though I never got around to look at his buggy code...)
<jkoenig> ok

IRC, freenode, #hurd, 2011-07-22

<pinotree> hm, why /proc/$pid/stat is 600 instead of 644 of linux?
<jkoenig> pinotree, it reveals information which, while not that sensitive,
  would not be available to users through the normal proc interface.
<jkoenig> (it's available through the ps command which is setuid root)
<jkoenig> we discussed at some point making it 644, IIRC.
<pinotree> hm, then why is it not a problem on eg linux?
<jkoenig> (btw you can change it with the -s option.)
<jkoenig> pinotree, it's not a problem because the information is not that
  sensitive, but when rewriting procfs I preferred to play it self and
  consider it's not procfs' job to decide what is sensitive or not.
<jkoenig> IIRC it's not sensitive but you need the task port to query it.
<jkoenig> like, thread times or something.
<pinotree> status is 644 though
<jkoenig> but status contains information which anyone can ask to the proc
  server anyway, I think.

/proc/mounts, /proc/[PID]/mounts

IRC, freenode, #hurd, 2011-07-25

< pinotree> jkoenig: btw, what do you think about providing empty
  /proc/mounts and /proc/$pid/mounts files?
< jkoenig> pinotree, I guess one would have to evaluate the consequences
  wrt. existing use cases (in other words, "I have absolutely no clue
  whatsoever about whether that would be desirable" :-)
< jkoenig> pinotree, the thing is, an error message like "/proc/mounts: No
  such file or directory" is rather explicit, whereas errors which would be
  caused by missing data in /proc/mounts would maybe be harder to track
< braunr> this seems reasonable though
< braunr> there already are many servers with e.g. grsecurity or chrooted
  environments where mounts is empty
< pinotree> well, currently we also have an empty mtab
< braunr> pinotree: but what do you need that for ?
< braunr> pinotree: the init system ?
< pinotree> and the mnt C api already returns no entries (or it bails out,
  i don't remember)
< pinotree> not a strict need

A mtab translator now exists.

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

<pinotree> teythoon: should procfs now have $pid/mounts files pointing to
<teythoon> pinotree: probably yes


Needed by glibc's pldd tool (commit 11988f8f9656042c3dfd9002ac85dff33173b9bd).


Needed by glibc's pldd tool (commit 11988f8f9656042c3dfd9002ac85dff33173b9bd).


id:"alpine.LFD.2.02.1110111111260.2016@akari". Needed by glibc's stdlib/tst-secure-getenv.c. Also used in [GCC]/libgfortran/runtime/main.c:store_exe_path.

Is it generally possible to use something like the following instead? Disadvantage is that every program using this needs to be patched.

#include <dlfcn.h>
Dl_info DLInfo;
int err = dladdr(&main, &DLInfo);
if (err == 0)
/* Pathname of shared object that contains address: DLInfo.dli_fname.  */
/* Filter it through realpath.  */

This is used in [LLVM]/lib/Support/Unix/Path.inc.

IRC, OFTC, #debian-hurd, 2013-11-10

<mjt> Hello.  Does hurd have /proc/self/exe equivalent, to "re-exec myself"
<youpi> no, only argv[0]
<mjt> busybox uses /proc/self/exe by default to re-exec itself when running
  one of its applets, or failing that, tries to find it in $PATH.  I guess
  it doesn't work on hurd... :)
<mjt> and argv0 is unreliable
<youpi> some discussion on the hurd wiki talks about using Dl_info DLInfo
<youpi> which contains DLInfo.dli_fname
<youpi> err, I mean, callling dladdr(&main, &DLInfo);
<youpi> this is kernel-agnostic, provided one uses glibc
<mjt> um. -ldl. nice for static linking
<mjt> gcc t.c -ldl -static
<mjt> ./a.out 
<mjt> fname=AVA� �j
<mjt> bah :)
<mjt> (it just prints dli_fname)
<teythoon> :/
<youpi> ah, yes, that won't work with static linking
<teythoon> fixing /proc/self is on my todo list, it shouldn't be too hard
<youpi> since in that case it's the exec server which sets the process up,
  not dl.so
<teythoon> but we do not have the exe link either
<mjt> (the above test run was on linux not on hurd, fwiw_
<mjt> )


IRC, freenode, #hurd, 2012-04-24

<antrik> braunr: /proc/*/fd can be implemented in several ways. none of
  them would require undue centralisation
<antrik> braunr: the easiest would be adding one more type of magic lookup
  to the existing magic lookup mechanism
<antrik> wait, I mean /proc/self... for /proc/*/fd it's even more
  straighforward -- we might even have a magic lookup for that already
<pinotree> i guess the ideal thing would be implement that fd logic in
<antrik> pinotree: nope. it doesn't need to ask proc (or any other server)
  at all. it's local information. that's what we have the magic lookups for
<antrik> one option we were considering at some point would be using the
  object migration mechanism, so the actual handling would still happen
  client-side, but the server could supply the code doing it. this would
  allow servers to add arbitrary magic lookup methods without any global
  modifications... but has other downsides :-)
<gnu_srs> youpi: How much info for /proc/*/fd is possible to get from
  libps? Re: d-h@
<youpi> see my mail
<youpi> I don't think there is an interface for that
<youpi> processes handle fds themselves
<youpi> so libps would have to peek in there
<youpi> and I don't remember having seen any code like that
<gnu_srs> 10:17:17< antrik> wait, I mean /proc/self... for /proc/*/fd it's
  even more straighforward -- we might even have a magic lookup for that
<gnu_srs> pinotree: For me that does not ring a bell on RPCs. Don't know
  what magic means,,
<youpi> for /proc/self/fd we have a magic lookup
<youpi> for /proc/pid/fd, I don't think we have
<gnu_srs> magic lookup*
<gnu_srs> magic lookup == RPC?
<youpi> magic lookup is a kind of answer to the lookup RPC
<youpi> that basically says "it's somewhere else, see there"
<youpi> the magic FD lookup tells the process "it's your FD number x"
<youpi> which works for /proc/self/fd, but not /proc/pid/fd
<civodul> youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that
  could be used
<civodul> `msgport' should have --get-fd, actually
<youpi> civodul: I assumed that the reason why msgport doesn't have it is
  that it didn't exist
<youpi> so we can get a port on the fd
<youpi> but then how to know what it is?
<civodul> youpi: ah, you mean for the /proc/X/fd symlinks?
<civodul> good question
<civodul> it's not designed to be mapped back to names, indeed :-)
<antrik> youpi: yeah, I realized myself that only /proc/self/fd is trivial
<antrik> BTW, in Linux it's nor real symlinks. it's magic, with some very
  strange (but useful in certain situations) semantics
<antrik> not real symlinks
<antrik> it's very weird for example for fd connected to files that have
  been unlinked. it looks like a broken symlink, but when dereferencing
  (e.g. with cp), you get the actual file contents...


GNU Savannah bug #32770

IRC, OFTC, #debian-hurd, 2012-06-20

<pinotree> bdefreese: the two elfutils tests fail because there are no
  /proc/$pid/maps files
<pinotree> that code is quite relying on linux features, like locating the
  linux kernel executables and their modules, etc
<pinotree> (see eg libdwfl/linux-kernel-modules.c)
<pinotree> refactor elfutils to have the linux parts executed only on linux
<bdefreese> Oh yeah, the maintainer already seems really thrilled about
  Hurd..  Did you see
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041 ?
<pinotree> kurt is generally helpful with us (= hurd)
<pinotree> most probably there he is complaining that we let elfutils build
  with nocheck (ie skipping the test suite run) instead of investigate and
  report why the test suite failed


Also used in [GCC]/intl/relocatable.c:find_shared_library_fullname for #ifdef __linux__.

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

<camm`> what's the equivalent of cat /proc/self/maps on hurd?
<braunr> camm`: for now, /proc/self doesn't work as expected
<camm`> thanks, I just want to get a list of maps and protection status for
  a running process -- how?
<braunr> vminfo
<camm`> thanks so much!  I'm trying to debug an unexec failure on hurd when
  a linker script is present.  All works with the default script, but when
  the text address is changed, unexec fails, running into a page with no
  access in the middle of the executable:    0xc4b000[0x1000] (prot=0,
  max_prot=RWX, offs=0xb55000)
<camm`> I get a segfault when trying to read from this page.
<braunr> unexec ?
<camm`> emacs/gcl/maxima/acl2/hol88/axiom use unexec to dump a running
  image into a saved executable elf file.
<braunr> what is unexec ?
<braunr> ok looks like a dirty tool
<braunr> camm`: what is segfaulting, unexec or the resulting executable ?
<camm`> unexec opens the file from which the running program was originally
  executed, finds its section start addresses, then writes a new file
  replacing any data in the old file with possibly modified versions in
  running memory.  The reverse of 'exec'.
<camm`> the read from running memory delimited by the addresses in the
  executable file is hitting a page which has been protected with *no*
  access, and is segfaulting.  Somehow, when the binary file is loaded,
  hurd turning off all rights to this page.
<camm`> let me check the stack location ...
<camm`> ok I think I've got it -- hurd moves the sbrk(0) address away from
  the end of .data (as reported by readelf) if the addresses are low,
  presumably to avoid running into the stack.
<camm`> starting sbrk(0)!=.data+data_size on hurd
<braunr> i'm not sure there is anything like the heap on the hurd
<braunr> sbrk is probably implemented on top of mmap
<braunr> camm`: hm no, i'm wrong, glibc implements brk and sbrk mostly as
  expected, but remapping the area isn't atomic
<braunr> "Now reallocate it with no access allowed"
<braunr> then, there is a call to vm_protect
<braunr> and no error checking
<braunr> ...
<camm`> ok, that's fine, but need to know -- in general there is no
  relationship between the address returned by sbrk(0) and the .data
  addresses reported by readelf on the file, (hurd only) yes?
<braunr> i don't know about that
<braunr> there should be ..
<camm`> Specific example: readelf -a ->   [24] .data             PROGBITS
  000f5580 0c4580 000328 00  WA  0   0 32
<camm`> sbrk(0)->(void *) 0x8021000
<braunr> camm`: is that on an executable or a shared object ?
<camm`> executable
<braunr> 000f5580 looks very low
<camm`> This is using a linker script.  The default setup works just fine.
<camm`> I think it (might) make sense for hurd to silently do this give the
  placement of the C stack, but the assumptions behind my algorithm need
  changing (perhaps). 
<camm`> (I probe in configure the allowable range of __executable_start,
  and then choose a value to either ensure a large free signed range around
  NULL, or a low data start to maximize heap)
<camm`> braunr: are there any guarantees of sbrk(0)==.data+size without a
  linker script?
<braunr> camm`: i'm not sure at all
<braunr> sbrk isn't even posix
<camm`> thanks

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

<ignaker> i'm trying to implement proc/maps 
<ignaker> actually I can't well evaluate complexity of tasks. However, I
  appreciate your comments
<braunr> the complexity can be roughly estimated from the number of
  components involved
<braunr> proc/maps involves procfs, ports, virtual memory, and file systems
<braunr> the naive implementation would merely be associating names to
  memory objects, and why not, but a more complete one would go ask file
  system servers about them
<braunr> perhaps more
<braunr> although personally i'd go for the naive one because less
  dependencies usually means better reliability
<braunr> something similar to task_set_name could do the job


Needed by glibc's pldd tool (commit 11988f8f9656042c3dfd9002ac85dff33173b9bd).


IRC, freenode, #hurd, 2012-06-30

* pinotree has a local work to add the /proc/$pid/cwd symlink, but relying
    on "internal" (but exported) glibc functions

CPU Usage

IRC, freenode, #hurd, 2013-01-30

<gnu_srs> Hi, htop seems to report CPU usage correct, but not top, is that
  a known issue? 
<youpi> does your /proc have the -c flag?
<gnu_srs> /hurd/procfs -c
<youpi> I don't remember which way it works, but iirc depending on whether
  -c is there or not, it will work or not
<youpi> problem being that nothing says linux' clock is 100Hz, but a lot of
  programs assume it
<gnu_srs> seems like htop gets it right though
<youpi> possibly just by luc
<youpi> k

IRC, freenode, #hurd, 2013-01-31

<braunr> both htop and top seem to have problems report the cpu time
<braunr> so i expect the problem to be in procfs

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

<braunr> teythoon: any reason the static variable translator_exists isn't
  protected by a lock in procfs/rootdir.c ?

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

<braunr> teythoon: can you tell me why translator_exists isn't protected
  from shared access in rootdir_mounts_exists ?
<teythoon> braunr: hm, dunno tbh, I probably thought the race was harmless
<braunr> it probably is
<braunr> settrans -Rg doesn't work on procfs :(

Kernel PID

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

<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
<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-04

<braunr> youpi: i fixed procfs on ironforge and exodar to be started as
  procfs -c -k 3
<braunr> without -k 3, many things as simple as top and uptime won't work

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