Merge remote-tracking branch 'dirichlet.SCHWINGE/master'

author: Thomas Schwinge <thomas@codesourcery.com> 2014-02-26 12:43:40 +0100
committer: Thomas Schwinge <thomas@codesourcery.com> 2014-02-26 12:43:40 +0100
commit: ca63bd2d33b3d28eabd50ad58577b52a1fc9eba0 (patch)
tree: 74bf46806011262f116d83ff5bec0a1cf8a79a4b /hurd
parent: 5757d0c3b11dac706fbe72247e9d2dcf0ff44df9 (diff)
parent: 7ffc398e1c386925826c42a30ff10ae84e79378f (diff)
19 files changed, 1475 insertions, 70 deletions
diff --git a/hurd/authentication.mdwn b/hurd/authentication.mdwn
index 2d6084bf..09dfb821 100644
--- a/hurd/authentication.mdwn
+++ b/hurd/authentication.mdwn
@@ -1,18 +1,22 @@
-[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
-UIDs on the Hurd are separate from processes.  A process has
+UIDs on the Hurd are separate from [[glibc/process]]es.  A process has
 [[capabilities|capability]] designating so-called UID vectors that
 are implemented by an [[translator/auth]] server.  This
 makes them easily [[virtualizable|virtualization]].
 
+The standard POSIX interfaces to a [[glibc/process]]' UID management are
+implemented in [[glibc]].
+
 When a process wishes to gain access to a resource provided by a third
 party (e.g., a file system) and that party wishes to authenticate the client
 so as to implement some identity-based access control ([[IBAC]]) policy,
@@ -25,3 +29,237 @@ naming a newly authenticated session with the server
 and the server is delivered the client's designated UID vector.
 
 For more details, see section 2.3 of the [[critique]].
+
+
+# Open Issues
+
+[[!tag open_issue_hurd]]
+
+
+## IRC, freenode, #hurd, 2013-09-26
+
+    <braunr> teythoon: hum, i just saw something disturbing
+    <braunr> teythoon: to isolate the leak, i created my own proc directory
+    <braunr> and the mtab translators it spawns seem to be owned by root oO
+    <teythoon> braunr: but how is that possible? are you sure? have you checked
+      with 'ids'?
+    <braunr> no i'm not sure
+    <braunr> also, ext2fs seems to ignore --writable when started as a passive
+      translator
+    <braunr> < teythoon> braunr: but how is that possible?
+    <braunr> messup with passive translators i guess
+    <braunr> teythoon: actually, it looks like it has effective/available id
+    <braunr> it has no*
+    <braunr> this feature doesn't map well in unix
+    <teythoon> braunr: ah yes, htop doesn't handle this well and shows root
+      indeed, our ps shows - as username
+    <braunr> yes
+
+
+## IRC, freenode, #hurd, 2013-09-28
+
+    <braunr> mhmm
+    <braunr> this process has no uid
+    <braunr> isn't it a security issue that processes can remove their identity
+      ?
+    <braunr> i really don't like that we allow processes to loose their
+      identity ...
+    <teythoon> braunr: y not? I think that's a killer feature
+    <teythoon> one that is notoriously absent in unices
+    <braunr> not exactly
+    <braunr> gaining rights to switch your identity is ok
+    <braunr> since you have proven that you are allowed to do it
+    <braunr> now, if you can remove your identity, you can create "ghost"
+      processes
+    <braunr> processes that can spend their day causing denial of services
+      without the possibility for the administrator to know who is responsible
+    <braunr> the unix "way" of dealing with DoS is to warn and ban users after
+      they violated the rules
+    <braunr> we need to have at least that possibility
+    <youpi> perhaps we need to add an "initial" uid
+    <teythoon> otoh the unix way of dropping privileges is hardly being able to
+      do so at all ;)
+    <braunr> teythoon: ?
+    <braunr> on unix, you need privileges to drop your identity :)
+    <braunr> i understand it involves security risks, but that's understandable
+    <braunr> the thing is, we actually don't care about dropping privileges
+    <braunr> we care about gaining them
+    <teythoon> you cannot drop your identity, you can just use another one
+    <braunr> exactly
+    <braunr> that's what i want
+    <braunr> and the way the hurd does it is superior
+    <braunr> let's keep that
+    <braunr> processes that should run with least privileges can simply have
+      their own user/group as it's done on unix
+    <teythoon> then how do you obtain such a uid/gid?
+    <braunr> teythoon: you gain the right, use it to prove who you can be, and
+      ask an identity switch
+    <braunr> identities would then be managed at server side (in proc for
+      example)
+    <teythoon> I know how it's done on the Hurd, but who creates them for you?
+    <braunr> the password server
+    <braunr> well no
+    <braunr> the password server gives you the right you need to prove who you
+      can be
+    <braunr> then i'd assume you'd ask the proc server for the switch
+    <teythoon> but who creates the uid for you in the first place, who sets up
+      a passwd entry
+    <braunr> the administrator ?
+    <braunr> what bothers me is that it goes directly against the main goal of
+      the hurd
+    <teythoon> indeed
+    <braunr> but i think it's a better compromise of freedom/order
+    <teythoon> I always thought that the ability to drop the unix-like
+      credentials is really nice
+
+
+### IRC, freenode, #hurd, 2013-09-29
+
+    <antrik> braunr: dropping privileges doesn't unregister a process from the
+      proc server... so it shouldn't be too hard to find out who is
+      responsible. however, there are more effective ways to create ghost
+      processes -- a special executable skipping the ordinary bootstrap won't
+      be registered with proc at all...
+    <antrik> however, that would be a non-issue if we had proper resource
+      accounting
+    <teythoon> antrik: I do not believe that this is correct. every mach task
+      will eventually be picked up by the proc server
+    <teythoon> eventually being next time someone fork(2)s or so
+    <teythoon> but if noone uses proc_child to claim the new process ones
+      child, it will not be presented by the proc server as unix process (aiui)
+    <antrik> teythoon: not sure what you mean by "pick up"
+    <antrik> of course proc will see the process when listing all tasks on the
+      system; but it will have no additional knowlegde about it
+    <antrik> (which is the whole purpose of proc)
+
+
+### IRC, freenode, #hurd, 2013-09-30
+
+    <braunr> antrik: proc should be redesigned to fix these issues
+    <braunr> in particular, the way that proc lists mach tasks to show them to
+      the rest of the system is something i find deeply disturbing
+    <braunr> hurd processes should be forced to go through proc
+    <antrik> braunr: well, if we are talking about fundamentally fixing things,
+      I believe the central proc server is not a good idea in the first place
+      :-)
+    <antrik> I believe hierarchical management of resource management and
+      information flow -- cf. nghurd and genode -- is a much better approach
+    <braunr> antrik: i agree with hierarchical management of resources, but i
+      don't see why this prevents a central proc server
+    <braunr> i.e. one proc server per hurd instance
+
+
+### IRC, freenode, #hurd, 2013-10-06
+
+    <antrik> braunr: hierarchical management of resources doesn't prevent a
+      central proc server of course; but a central proc server would fit really
+      ill with hierarchical management of permissions...
+
+
+### IRC, freenode, #hurd, 2013-10-07
+
+    <braunr> antrik: does proc manage permissions ?
+    <antrik> braunr: well, it manages some permissions... like who is allowed
+      to send signals
+    <antrik> hm... or perhaps proc is not involved in signal delivery itself?
+      don't remember. but at any rate, proc decides whether it hands out
+      privileged task ports
+    <braunr> antrik: yes, it decides whether or not a client is allowed to
+      obtain the message port of another task
+    <braunr> antrik: but i don't see why this is a problem
+    <braunr> what we have now is one proc server per hurd instance
+    <braunr> how is that not both central (inside the hurd instance) and
+      hierarchical with regard to resource management ?
+    <antrik> braunr: we are probably talking past each other
+    <antrik> all I'm saying is that in an ideal world, there should not be a
+      central server deciding who is allowed to see and/or control other
+      processes
+    <braunr> antrik: how should it be structured then ?
+    <braunr> i mean, how would you see it ?
+    <antrik> child processes should be fully controlled by their parent --
+      including outside communication
+    <antrik> (like in genode AIUI)
+    <braunr> isn't that conflicting with the unix design ?
+    <kilobug> antrik: maybe I'm saying silly stuff since I don't have all the
+      background, but seems problematic to me with SUID/SGID programs
+    <kilobug> antrik: in which a child can be more privilegied than the parent
+    <braunr> kilobug: that's part of my question too
+    <kilobug> and it's even "worse" with Hurd's addauth in which any process
+      can be given additional rights in runtime, but not its parent
+    <antrik> braunr: one of the conclusions from ngHurd was that suid as such
+      is problematic. it makes more sense to have privileged services actually
+      run by the privileged user, and only requested by the unprivileged one
+      using RPC
+    <antrik> admittedly, I'm not sure how this interacts with UNIX
+      compatibility ;-)
+    <antrik> kilobug: in the genode approach, the parent would control that as
+      well
+    <braunr> in unix, the idea of parent processes doesn't imply much
+    <braunr> parents merely exist to reap resources from their children
+    <braunr> and as templates when forking
+    <antrik> yeah, but that's one of the major shortcomings of UNIX in my
+      book...
+    <braunr> sure
+    <braunr> i'm just thinking out loud
+    <braunr> if we want to maintain posix compatibility, it seems reasonable to
+      keep it that way
+    <braunr> despite the shortcomings
+    <braunr> does that imply a centralized proc server anyway ?
+    <antrik> I suspect we could similate suid in the hierarchical design, only
+      that the resources would be accounted to the user under whose ID the
+      process runs, rather than to the one who invoked it
+    <braunr> i also have a hard time seeing what the completely hierarchical
+      model brings compared to what the hurd does (isolating system instances)
+    <antrik> and I don't think we need a central proc server. it could probably
+      be done similar to the VFS: each process implements the interfaces,
+      passing on to the children as appropriate
+    <antrik> braunr: it's much easier to isolate parts of the system for
+      security and/or customisation
+    <antrik> that's actually one of the things discussed in the "critique"
+      IIRC...
+    <braunr> i'm not sure
+    <braunr> anyway, processes implementing the interface looks bad to me
+    <braunr> that's already a problem with the current hurd
+    <braunr> using normal client processes as servers means we rely on them to
+      behave nicely
+    <antrik> you have a point there: while untrusted filesystems can be ignored
+      easily, ignoring untrusted proc providers would be problematic...
+    <antrik> (I don't think it's strictly necessary to know about other user's
+      processes; but we could hardly keep a UNIX feel without it...)
+    <antrik> other users'
+    <braunr> i feel the hierarchical model may imply some unnecessary burden
+    <braunr> capabilities along with resource containers look much more
+      flexible
+    <braunr> and not less secure
+    <braunr> children would share the same container as their parent by
+      default, unless they obtain the right to use another or create their own
+    <antrik> braunr: decoupling control from resource ownership is *always*
+      problematic. that's pretty much the major takeaway from ngHurd
+      discussions (and the major reason why Coyotos was abandoned as a base for
+      ngHurd)
+    <antrik> if a process runs on your resources, you should have full control
+      over it. anything else faciliates DRM & Co.
+    <braunr> antrik: i see
+    <braunr> nonetheless, i don't see the point of that restriction, since the
+      simplest way to avoid drms in the first place is not using them
+    <braunr> and that restriction makes posix compatibility hard to provide
+    <antrik> I'm not sure it's really all that hard...
+    <antrik> IIRC genode is aiming at POSIX compatibility
+    <antrik> I'm not sure it's any harder than with the current Hurd
+      architecture
+    <braunr> i didn't see anything like that
+    <braunr> they provide posix compatibility by running legacy systems on top
+      of it
+    <braunr> well, namely linux
+    <antrik> hm... they have some UNIX compatibility at least... perhaps not
+      aiming at full POSIX. don't remember the details
+    <antrik> Linux on genode? that's news to me... I know they do run genode on
+      Linux
+    <braunr> anyway, i'll probably stick with the close unix approach for x15
+    <braunr> http://genode.org/documentation/general-overview/
+    <braunr>  In an preliminary study, a user-level version of the Linux kernel
+      (L4Linux) was successfully ported to the Genode OS Framework running on a
+      L4 kernel. This study suggests that Genode combined with an appropriate
+      kernel or hypervisor is suited as a virtual-machine hosting platform.
+    <antrik> hm... that's boring though ;-)
+    <braunr> isn't it :)
diff --git a/hurd/console.mdwn b/hurd/console.mdwn
index 55581870..10c74bf9 100644
--- a/hurd/console.mdwn
+++ b/hurd/console.mdwn
@@ -1,5 +1,5 @@
 [[!meta copyright="Copyright © 2002, 2003, 2004, 2005, 2006, 2007, 2009, 2011,
-2012 Free Software Foundation, Inc."]]
+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
@@ -37,8 +37,8 @@ where the numbered nodes represent virtual consoles and their contents are all
 alike.
 
 As the following graph shows, the console, input and display nodes are the
-interfaces used by the terminal server, input driver and display drivers
-respectively.
+interfaces used by the [[terminal server|translator/term]], input driver and
+display drivers respectively.
 
        +------------------+                                 +-----------------+
        |   Input driver   |                                 | Terminal Server |
@@ -67,7 +67,8 @@ respectively.
        +----------------+                                   +-----------------+
 
 The input driver takes scancodes from the in-kernel kbd queue, translates them
-into characters and writes them to the input node.  Then the terminal server
+into characters and writes them to the input node.  Then the [[terminal
+server|translator/term]]
 reads the console node taking the characters out of the console server.
 
 Each of theese actions is actually an RPC handled by the translator on
@@ -110,7 +111,8 @@ Additional information about the console can be found in the [Hurd Console Tutor
 
 **_The new Hurd console features:_**
 
-**A console server**, which provides a number of virtual consoles to term servers, with a full set of terminal capabilities.
+**A console server**, which provides a number of virtual consoles to [[term
+servers|translator/term]], with a full set of terminal capabilities.
 
 The console server supports any encoding supported by iconv, but uses Unicode internally. The default encoding is ISO8859-1, another useful variant is UTF-8.
 
@@ -307,7 +309,13 @@ If you use mutt, install `mutt-utf8` package. For lynx, edit `/etc/lynx.cfg`, ma
 
 If you use other applications, try to search with google for "application-name utf8" or "application-name unicode". Often you find what you need. The issues are the same for the GNU/Hurd and GNU/Linux systems, so most of the information can be shared, except how to setup the system console to support Unicode, of course.
 
-The `console-server` watches for new hurdio terms (devices translated with `/hurd/term`) and adds them to `/dev/vcs` automatically. What this means is, if you create a new tty with `MAKEDEV`, and then attach something to it, it will now appear in `/dev/vcs`. When a term is disconnected from, it disappears from `/dev/vcs`. `/libexec/getty` is what is usually attached to a term. You can see this automatic adding and removing of terms from the `console-server` by typing the following:
+The `console-server` watches for new [[hurdio terms (devices translated with
+`/hurd/term`)|translator/term]] and adds them to `/dev/vcs` automatically.
+What this means is, if you create a new tty with `MAKEDEV`, and then attach
+something to it, it will now appear in `/dev/vcs`.  When a term is disconnected
+from, it disappears from `/dev/vcs`.  `/libexec/getty` is what is usually
+attached to a term.  You can see this automatic adding and removing of terms
+from the `console-server` by typing the following:
 
     # cd /dev
     # ls vcs/
diff --git a/hurd/console/discussion.mdwn b/hurd/console/discussion.mdwn
index 0022ec23..73d605ed 100644
--- a/hurd/console/discussion.mdwn
+++ b/hurd/console/discussion.mdwn
@@ -48,3 +48,50 @@ License|/fdl]]."]]"""]]
 
     <pinotree> http://xkbcommon.org/ ¡û sounds interesting for our console
       translator
+
+
+# IRC, freenode, #hurd, 2013-10-01
+
+[[!tag open_issue_hurd]]
+
+    <pinotree> teythoon_: df: `/dev/cons': Operation not supported
+    <pinotree> missing/stub implementation in the console translator?
+
+
+## IRC, freenode, #hurd, 2013-10-02
+
+    <teythoon_> pinotree: yes, df does file_statfs which fails
+
+
+# IRC, freenode, #hurd, 2013-10-22
+
+    <C-Keen> hello hurders! I happened to watch samuel's gnu hackers talk and
+      wanted to start to use the hurd more regularily. However I noticed that
+      when I use the preinstalled image, there seems to be some issue with the
+      console driver
+    <C-Keen> when I start emacs the mode line is drawn 3 times above the bottom
+      of the screen
+    <C-Keen> is this know or did I miss a step in setting it up? Or should I
+      use the debian installer and start from scratch again?
+    <youpi> C-Keen: it's probably unknown, and not an issue on your side. Did
+      you try to upgrade to the latest packages?
+    <C-Keen> youpi: doing that now
+    <C-Keen> my base image is debian-hurd-20130504.img
+    <youpi> still an issue with the latest packages indeed
+    <youpi> it seems emacs and the hurd console don't agree on the number of
+      lines...
+    <youpi> C-Keen: you can set TERM=vt100 to work around the issue
+    <C-Keen> ah alright.
+    <youpi> or TERM=linux
+    <C-Keen> youpi: can you start the emacs in X? I get an empty window here
+    <youpi> I never tried
+    <youpi> I never use emacs :)
+    <C-Keen> I see ;)
+    <youpi> it seems there's a bug in cud1 indeed
+    <C-Keen> what's cud1?
+    <youpi> see man 5 terminfo
+    <braunr> yes it's a terminfo problem
+    <braunr> the hurd console isn't well defined there
+    <youpi> braunr: actually it seems like a bug in emacs
+    <youpi> cud may or may not scroll the screen, depending on the
+      implementation
diff --git a/hurd/libfuse.mdwn b/hurd/libfuse.mdwn
index 78e96022..28125dd9 100644
--- a/hurd/libfuse.mdwn
+++ b/hurd/libfuse.mdwn
@@ -49,6 +49,25 @@ etc.
     <braunr> and they could almost readily use our libfuse version
 
 
+## IRC, freenode, #hurd, 2013-10-01
+
+    <pinotree> our libfuse implementation is still basic atm (there's a wiki
+      page about it)
+    <alsuren> okay... talk to me about FUSE
+    <pinotree> even with the improvements i have in my public branch, it still
+      cannot do real-world fs'es
+    <alsuren> okay, so you're the person to ask about FUSE
+    <alsuren> it strikes me that HURD not having FUSE support is a bit of an
+      architectural oversight
+    <pinotree> i'm not sure what's your point about fuse, since what fuse on
+      linux (and not only) does is done *natively* by the hurd
+    <alsuren> exactly
+    <pinotree> all of the hurd filesystems (which are just a type of servers)
+      run in userspace already
+    <alsuren> so FUSE should Just Work
+    <pinotree> well no
+
+
 # Source
 
 [[source_repositories/incubator]], libfuse/master.
diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn
index d28a777e..a9acd9f9 100644
--- a/hurd/porting/guidelines.mdwn
+++ b/hurd/porting/guidelines.mdwn
@@ -1,5 +1,5 @@
 [[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010, 2011,
-2012 Free Software Foundation, Inc."]]
+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
@@ -83,6 +83,24 @@ because else *-gnu* would catch i386-pc-linux-gnu for instance...
 
 Note: some of such statements are not from the source package itself, but from aclocal.m4 which is actually from libtool. In such case, the package simply needs to be re-libtoolize-d.
 
+
+## Preprocessor Define
+
+### IRC, freenode, #hurd, 2013-10-23
+
+    <C-Keen> Is there a preprocessor define gcc sets for hurd which I can check
+      in my code?
+    <braunr> __GNU__
+    <braunr> glibc sets it if i'm right
+    <C-Keen> I also see that __MACH__ gets set
+    <azeem> that's also set on Mac OS X
+    <C-Keen> right, which uncovered a bug in the code
+    <braunr> the microkernel doesn't always implies what operating system runs
+      on top of it
+    <C-Keen> braunr: but __GNU__ is the correct define for hurd specific code?
+    <braunr> yes
+
+
 ## <a name="Undefined_bits_confname_h_tt_mac"> Undefined `bits/confname.h` macros (`PIPE_BUF`, ...) </a>
 
 If macro `XXX` is undefined, but macro `_SC_XXX` or `_PC_XXX` is defined in `bits/confname.h`, you probably need to use `sysconf`, `pathconf` or `fpathconf` to obtain it dynamicaly.
diff --git a/hurd/running/virtualbox.mdwn b/hurd/running/virtualbox.mdwn
index 822f771d..23a0b156 100644
--- a/hurd/running/virtualbox.mdwn
+++ b/hurd/running/virtualbox.mdwn
@@ -40,7 +40,44 @@ To convert the image you need the VirtualBox package properly installed with a V
 If [[QEMU with KVM|qemu]] is not available, VirtualBox reportedly has better
 performance.
 
-IRC, freenode, #hurd, 2011-10-31:
+
+# Open Issues
+
+## IRC, freenode, #hurd, 2011-10-31
 
     <youpi> I don't know what virtualbox does with hardware emulation, but
       gnumach is awfully slow to probe things there
+
+
+## IRC, freenode, #hurd, 2013-09-28
+
+    <snadge> the problem is if i giveit more than 1855 it says truncating to
+      that
+    <snadge> so i give it that.. then it has kmem alloc error
+    <snadge> 1536mb same.. 1024 isok
+    <braunr> hum
+    <braunr> that's weird
+    <braunr> virtual box ?
+    <snadge> yeah
+    <snadge> i wonder what cpu features i should enable/disable
+    <snadge> pae ?
+    <braunr> make sure vbox doesn't count on the so called memory balloon
+    <braunr> pae isn't used except on xen
+    <braunr> disable apic
+    <braunr> enable host io cache in disk controllers
+    <youpi> do we have these written on the wiki?
+    <braunr> no because i didn't run into these problems
+    <braunr> but since i know the system well enough to avoid them in the first
+      place ..
+    <braunr> we need real users to report them
+    <braunr> i'm not sure we have anything about vbox in the wiki actually
+    <youpi> ./hurd/running/virtualbox.mdwn
+    <youpi> we seem to have a page at least
+    <snadge> it seems to be okay with 1024MiB
+    <braunr> still weird
+    <braunr> looks more random than buggy with more memory
+    <braunr> do you have the exact error message you got during your previous
+      attempts ?
+    <snadge> no.. i should have taken a screenshot.. its easy enough to
+      reproduce though
+    <snadge> i'll wait until after its installed
diff --git a/hurd/status.mdwn b/hurd/status.mdwn
index cca8fc15..6aa319d1 100644
--- a/hurd/status.mdwn
+++ b/hurd/status.mdwn
@@ -38,15 +38,10 @@ Although the [[POSIX
 interface|faq/posix_compatibility]] is provided, some additional interfaces
 like POSIX shared memory or semaphores are still under development.
 
-All this applies to the current development version, and not to the
-last release (0.2).  We encourage everybody who is interested to try
+We encourage everybody who is interested to try
 out the current development version, and send feedback to the Hurd
 developers.
 
-The Hurd team doesn't create Hurd-only releases, but instead relies on
-the distributions done by folks from *Debian*, *Arch* (since 2010), and *Nix*
-(since 2012).
-
 [[!img hurd-iceweasel-screenshot-2012-03-21.png size=300x
 alt="Iceweasel running on GNU/Hurd"
 title="Iceweasel running on GNU/Hurd"
@@ -63,17 +58,6 @@ GNU/Hurd 2013|news/2013-05-debian_gnu_hurd_2013]].
 
 [[hurd/running/Nix]] provides QEMU images.
 
-That said, the last official release of the Hurd 
-without the Debian parts was 0.2 done in 1997 ([[history]]).
-
-New official releases will be done, as soon as 
-the Hurd is sufficently stable and feature
-complete.  If an official release of the Hurd were made
-now, people would try the Hurd and be disappointed.  People
-already expect delays; to disappoint them in this way as
-well would be unfortunate. Moreover, it would lessen the
-possibility that they would want to try the Hurd again in the future.
-
 
 ## Usability Reports
 
diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn
index fac93625..892387ef 100644
--- a/hurd/subhurd/discussion.mdwn
+++ b/hurd/subhurd/discussion.mdwn
@@ -180,3 +180,37 @@ License|/fdl]]."]]"""]]
     <braunr> safer
     <braunr> perhaps more powerful too, but that entirely depends on the
       features you want inside
+
+
+# IRC, freenode, #hurd, 2013-10-04
+
+    <braunr> hm, looks like we broke subhurds again
+    <braunr> freezes after starting exec
+    <teythoon> o_O
+    <braunr> looks like some translator refuses to start
+    <braunr> teythoon: we need better error reporting first :)
+
+[[open_issues/subhurd_error_messages]].
+
+    <braunr> and better visibility in general
+    <braunr> teythoon: it may be that the subhurd i'm using is a bit od
+    <braunr> old
+    <braunr> one weird thing about subhurds is that they actually use the
+      ext2fs and linker from the host
+    <braunr> so it's better if the subhurd and the host uses the same bootstrap
+      protocol :)
+    <teythoon> braunr: isn't boot --boot-root=DIR there to specify which root
+      translator and linker to use?
+    <braunr> teythoon: yes but you don't want your root file system mounted
+      from the host when starting your subhurd
+    <teythoon> you can mount it r/o just fine, no?
+    <braunr> ideally, we'd have a userspace version of grub reading the files
+      from the disk, as it's done when booting
+    <braunr> hm
+    <braunr> right
+
+
+## IRC, freenode, #hurd, 2013-10-07
+
+    <teythoon> braunr: btw, did you straighten out your subhurd issue?
+    <braunr> teythoon: no i haven't
diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index 52cd09f7..32562a8b 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -106,6 +106,7 @@ The [[concept|concepts]] of translators creates its own problems, too:
 * [[symlink]]
 * [[firmlink]]
 * [[fifo]]
+* [[term]]
 * ...
 
 
diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn
index 7fd4832c..10cfb3aa 100644
--- a/hurd/translator/auth.mdwn
+++ b/hurd/translator/auth.mdwn
@@ -8,7 +8,8 @@ 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 *auth server* (or, *authentification server*).
+The *auth server* (or, *authentification server*) is a key component managing
+[[authentication]] in a Hurd system.
 
 It is stated by `/hurd/init`.
 
diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn
index e038ba84..95f5ab0c 100644
--- a/hurd/translator/discussion.mdwn
+++ b/hurd/translator/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 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
@@ -10,7 +10,8 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_documentation open_issue_hurd]]
 
-IRC, freenode, #hurd, 2011-08-25:
+
+# IRC, freenode, #hurd, 2011-08-25
 
     < frhodes> how can I replace an existing running server with a new one
       without rebooting?
@@ -23,3 +24,24 @@ IRC, freenode, #hurd, 2011-08-25:
       nature
     < antrik> in some cases, you might even be able simply to remove the old
       translator... but obviously only for non-critical stuff :-)
+
+
+# IRC, freenode, #hurd, 2013-10-21
+
+    <braunr> mhmm, there is a problem with thread destruction
+
+[[open_issues/libpthread/t/fix_have_kernel_resources]].
+
+    <braunr> actually, translator self destruction
+    <braunr> if a request arrives after the last thread servicing a port set
+      returns from mach_msg because of a timeout, but before the translator is
+      detached from its parent, the client will get an error
+    <braunr> it should very rarely happen, but if it does, we could face the
+      same kind of issues we have when a server crashes
+    <braunr> e.g. sshd looping over select() returning EBADF, consuming all cpu
+    <braunr> not sure we want to introduce such new issues
+
+    <braunr> i don't think i'll be able to make translators disappear reliably
+      ..
+    <braunr> but at least, thread consumption will correctly decrease with
+      inactivity
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index e2f6b044..cfd09502 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -163,6 +163,11 @@ small backend stores, like floppy devices.
     <youpi> ok
 
 
+#### IRC, freenode, #hurd, 2013-10-08
+
+    <braunr> ogi: your ext2fs patches were finally merged upstream :)
+
+
 ## Sync Interval
 
 [[!tag open_issue_hurd]]
@@ -209,39 +214,6 @@ That would be a nice improvement, but only after writeback throttling is impleme
     <teythoon> tschwinge: well, thanks anyway ;)
 
 
-## Increased Memory Consumption
-
-### IRC, freenode, #hurd, 2013-09-18
-
-    <braunr> ext2fs is using a ginormous amount of memory on darnassus since i
-      last updated the hurd package :/
-    <braunr> i wonder if my ext2fs large store patches rework have introduced a
-      regression
-    <braunr> the order of magnitude here is around 1.5G virtual space :/
-    <braunr> it used to take up to 3 times less before that
-    <braunr> looks like my patches didn't make it into the latest hurd package
-    <braunr> teythoon: looks like there definitely is a new leak in ext2fs
-    <teythoon> :/
-    <braunr> memory only
-    <braunr> the number of ports looks stable relative to file system usage
-    <teythoon> braunr: I tested my patches on my development machine, it's up
-      for 14 days (yay libvirt :) and never encountered problems like this
-    <braunr> i've been building glibc to reach that state
-    <teythoon> hm, that's a heavy load indeed
-    <teythoon> could be the file name tracking stuff, I tried to make sure that
-      everything is freed, but I might have missed something
-    <braunr> teythoon: simply running htop run shows a slight, regular increase
-      in physical memory usage in ext2fs
-    <pinotree> old procfs stikes again? :)
-    <teythoon> braunr: I see that as well... curious...
-    <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried
-      to make sure that everything is freed, but I might have missed something
-    <braunr> how knows, maybe completely unrelated
-    <teythoon> the tracking patch isn't that big, I've gone over it twice today
-      and it still seems reasonable to me
-    <braunr> hm
-
-
 # Documentation
 
   * <http://e2fsprogs.sourceforge.net/ext2.html>
diff --git a/hurd/translator/fifo.mdwn b/hurd/translator/fifo.mdwn
index 857922fc..4132e94a 100644
--- a/hurd/translator/fifo.mdwn
+++ b/hurd/translator/fifo.mdwn
@@ -46,3 +46,9 @@ The *fifo* translator implements named pipes (FIFOs).
     <pochu> gg0: got an example?
     <gg0> http://bugs.debian.org/629184
     <gg0> i didn't close it myself
+
+
+## IRC, OFTC, #debian-hurd, 2013-10-04
+
+    <braunr> there is new-fifo, which you can try
+    <braunr> i guess none of us know what it was really meant for
diff --git a/hurd/translator/magic.mdwn b/hurd/translator/magic.mdwn
index 84bacdfb..2b0d1bf7 100644
--- a/hurd/translator/magic.mdwn
+++ b/hurd/translator/magic.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2006, 2007, 2008, 2010 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2006, 2007, 2008, 2010, 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
@@ -9,7 +9,13 @@ 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 magic translator provides `/dev/fd`.
+The `magic` translator returns magic retry results, which are then resolved by
+[[glibc]]'s *name lookup* routines.
+
+[[!toc]]
+
+
+# `/dev/fd`.
 
     $ showtrans /dev/fd
     /hurd/magic --directory fd
@@ -20,3 +26,253 @@ individually like this:
 
     $ ls -l /dev/fd/0
     crw--w----  1 bing tty 0, 0 Nov 19 18:00 /dev/fd/0
+
+
+# `/dev/tty`
+
+    $ showtrans /dev/tty
+    /hurd/magic tty
+
+
+## Open Issues
+
+### IRC, OFTC, #debian-hurd, 2013-06-18
+
+    <XTaran> http://www.zsh.org/mla/workers/2013/msg00547.html
+
+
+#### IRC, OFTC, #debian-hurd, 2013-06-19
+
+    <XTaran> youpi: http://www.zsh.org/mla/workers/2013/msg00548.html -- Is
+      that realistic? If yes, can someone of you test it? I though would expect
+      that if /dev/tty exists everywhere, it's a chardev everywhere, too.
+    <youpi> that's not impossible indeed
+    <youpi> I've noted it on my TODO list
+
+
+#### IRC, OFTC, #debian-hurd, 2013-06-20
+
+    <pinotree> youpi: wrt the /dev/tty existance,
+      https://buildd.debian.org/status/fetch.php?pkg=mksh&arch=hurd-i386&ver=46-2&stamp=1371553966
+    <pinotree> For the build logs, demonstrate that /dev/null and /dev/tty
+      exist:
+    <pinotree> ls: cannot access /dev/tty: No such device or address
+    <youpi> uh?!
+    <youpi> ah, ENODEV
+    <youpi> so that's what we was thinking, no tty -> no /dev/tty
+
+
+#### IRC, OFTC, #debian-hurd, 2013-09-20
+
+    <XTaran> Hi. zsh still FTBFS on Hurd due to some test failure:
+      https://buildd.debian.org/status/package.php?p=zsh -- IIRC I checked last
+      time on some porterbox and couldn't reproduce the failure there. Any
+      insight if /dev/tty is not accessible on the buildds inside the chroot?
+      Or is it no character device there? I checked on strauss and there it is
+      a character device.
+    <XTaran> My only other option to debug this (didn't think of that yesterday
+      before the upload unfortunately) would be to override dh_auto_test with
+      "ls -l /dev/tty; dh_auto_test". Do you think that would be helpful?
+    <pinotree> i see /dev/tty on exodar, in the root system and in the chroot
+    <XTaran> pinotree: And it is a character device?
+    <XTaran> ... in both cases?
+    <pinotree> crw--w---- 1 pino tty 0, 0 Sep 20 10:20 /dev/tty
+    <pinotree> yes
+    <XTaran> pinotree: Hrm.
+    <pinotree> (/dev in the chroot is a firmlink to the system /dev, iirc)
+    <XTaran> pinotree: What is a firmlink? :)
+    <XTaran> pinotree: /dev/tty belongs to your user in the example above.
+    <pinotree> something between a (sym)link and an union mount
+    <XTaran> pinotree: Is it possible that /dev/tty is not visible if the
+      buildd runs without a connected terminal?
+    <pinotree> that i'm not sure
+    <XTaran> I see.
+    <pinotree> wouldn't it be possible to skip only that check, instead of the
+      whole test suite?
+    <pinotree> maybe something like
+    <pinotree> tty=$(find /dev/ -name 'tty*' -type c -print)
+    <pinotree> if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c $zerolength ]]
+      / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty ]] (no tty
+      found)' / [[ ! -c $zerolength ]] / fi
+    <pinotree> (never used zsh, so please excuse me if i wrote something silly
+      above)
+    <XTaran> re
+    <XTaran> pinotree: Yeah, sure. That would be one way to get the thing
+      building again, if that's really the cause.
+    <pinotree> i guess it would find any of the available tty* devices
+    <pinotree> it does that for block devices, why not with tty devices, after
+      all? :)
+    <XTaran> pinotree: I just wonder if the failing test is because the test
+      doesn't work properly on that architecture or because it indicates that
+      there is a bug in zsh which only is present on hurd.
+    <pinotree> wouldn't the change proposed above help in determining it?
+    <XTaran> If I'm sure that it's a broken test, I'll try to disable that
+      one. If not I'd report (more details) to upstream. :)
+    <XTaran> pinotree: Oh, indeed.
+    <pinotree> if you get no warning, then a tty device was found with find
+      (using its -type c option), so the failing condition would be a zsh (or
+      maybe something in the stack below) bug
+    <pinotree> with the warning, somehow there were no tty devices available,
+      hence nothing to test -c with
+    <XTaran> So basically doing a check with dash to see if we should run the
+      zsh test.
+    <pinotree> dash?
+    <XTaran> Well, whatever /bin/sh points to. :)
+    <pinotree> ah, do you mean because of $(find ...)?
+    <XTaran> Ah, right, -type c is from find not /bin/sh
+    <XTaran> pinotree: That's my try:
+      http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=ba5c7320d4876deb14dba60584fcdf5d5774e13b
+    <pinotree> o_O
+    <pinotree> isn't that a bit... overcomplicated?
+    <XTaran> pinotree: Yeah, it's a little bit more complicated as the tests
+      itself are not pure shell code but some format on their own.
+    <pinotree> why not the "thing" i wrote earlier?
+    <XTaran> pinotree: Actually it is what I understand you wanted to do, just
+      with more debug output. Or I dunderstood 
+    <XTaran> pinotree: Actually it is what I understand you wanted to do, just
+      with more debug output. Or I understood your thing wrongly.
+    <pinotree> <pinotree> tty=$(find /dev/ -name 'tty*' -type c -print)
+    <pinotree> <pinotree> if [[ -n $tty ]]; then / [[ -c $tty[(f)1] && ! -c
+      $zerolength ]] / else / print -u$ZTST_fd 'Warning: Not testing [[ -c tty
+      ]] (no tty found)' / [[ ! -c $zerolength ]] / fi
+    <XTaran> pinotree: Yeah, I know.
+    <pinotree> that is, putting these lines instead of the current two
+      tty=/dev/tty + following
+    <pinotree> imho that should be fit for upstream
+    <XTaran> pinotree: You mean inside C02cond.ztst?
+    <pinotree> yep
+    <XTaran> pinotree: No, IMHO that's a bad idea.
+    <pinotree> why?
+    <XTaran> pinotree: That file is to test the freshly compiled zsh. I can't
+      rely on their code if I'm testing it.
+    <pinotree> uh?
+    <pinotree> the test above for -b is basically doing the same
+    <XTaran> pinotree: Indeed. Hrm.
+    <pinotree> that's where i did c&p most of it :)
+    <XTaran> So upstream relies on -n in the testsuite before it has tested it?
+      Ugly.
+    <pinotree> if upstream does it, why cannot i too? :D
+    <XTaran> pinotree: You've got a point there.
+    <XTaran> Ok, rethinking. :)
+    <pinotree> otoh you could just move the testcase for -n up to that file, so
+      after that you know it works already
+    <XTaran> pinotree: Well, if so, upstream should do that, not me. :)
+    <pinotree> you could suggest them to, given the -n usage in the -b testcase
+    <XTaran> pinotree: Looks alphabetically sorted, so I guess that's at least
+      not accidentially.
+    <XTaran> pinotree: Ok, you've convinced me. :)
+    <pinotree> :D
+    <XTaran> Especially because this is upstream-suitable once it proved to fix
+      the Hurd FTBFS. :)
+    <XTaran> pinotree: The previous upstream code (laast change 2001) instead
+      of the hardcoded /dev/tty was btw "char=(/dev/tty*([1]))", so I suspect
+      that the find may work on Cygwin, too.
+    <XTaran> s/aa/a/
+    <pinotree> ah, so that's that comment about globbing on cygwin was
+      referring to
+    <XTaran> Yep
+    <pinotree> cool, so incidentally i've solved also that small issue :9
+    <pinotree> :)
+    <XTaran> pinotree: I hope so. :)
+    <XTaran> Then again, I hope, external commands like find are fine for
+      upstream.
+    <pinotree> then they should rework the already existing testcases ;)
+    <XTaran> pinotree: Ah, I fall again for the same assumptions. :)
+    <XTaran> Seems as I would really build test suites with a different
+      approach. :)
+    <pinotree> nothing bad in that, i'd say
+    <XTaran> I'd try to make the tests as far as possible independent from
+      other tools or features to be sure to test only the stuff I want to test.
+    <XTaran> Warning: Not testing [[ -c tty ]] (no tty found)
+    <XTaran> Interesting. I didn't expect that outside a chroot. :)
+    <pinotree> where's that?
+    <XTaran> pinotree: A plain "debuild on my Sid VM.
+    <pinotree> ah
+    <XTaran> Linux, amd64
+    <XTaran> (and Debian of course ;-)
+    <XTaran> pinotree: Ah, my fault, I kept upstreams char= but didn't change
+      it in your code. :)
+    <pinotree> hehe
+    <XTaran> pinotree: Will be included in the next zsh upload. But I don't
+      want to upload a new package before the current one moved to testing (or
+      got an RC bug report to fix :-)
+    <pinotree> oh sure, that's fine
+    <XTaran> pinotree:
+      http://anonscm.debian.org/gitweb/?p=collab-maint/zsh.git;a=commitdiff;h=22bc9278997a8172766538a2ec6613524df03742
+    <XTaran> (I've reverted my previous commit)
+    <pinotree> \o/
+
+
+#### IRC, OFTC, #debian-hurd, 2013-09-30
+
+    <XTaran> Anyone knows why the building of zsh on ironforge restarted? It
+      was at something like "building 4h20m" when I looked last and it now is
+      at "building 1h17m" but there's no old or last log, so it does still look
+      like the first build.
+    <pinotree> most probably got stuck
+    <XTaran> Oh, ok.
+    <XTaran> pinotree: So there are cases where the log is not kept?
+    <pinotree> looks so
+    <youpi> when the machine crashes, yes :)
+    <XTaran> youpi: Ooops. Was that me?
+    <youpi> no, I just rebooted the box
+    <youpi> I didn't easily find which process to kill
+    <XTaran> Ok. Then I'll check back tomorrow morning if pinotree's fix for
+      zsh's test suite on hurd worked. :)
+    <youpi> it seems to be hung on
+      /build/buildd-zsh_5.0.2-5-hurd-i386-vO9pnz/zsh-5.0.2/obj/Test/../Src/zsh
+    <youpi> ../Src/zsh   ../../Test/ztst.zsh ../../Test/Y02compmatch.ztst
+    <XTaran> :(
+    <XTaran> At least pinotree's patch worked as it then likely passed
+      C02cond.ztst. :)
+    <XTaran> youpi: For how long? There are multiple tests which take at least
+      3 seconds per subtest.
+    <youpi> one hour already
+    <XTaran> Ok.
+    <XTaran> That's far too long
+
+
+#### IRC, OFTC, #debian-hurd, 2013-10-01
+
+    <XTaran> pinotree: I've just checked
+      https://buildd.debian.org/status/fetch.php?pkg=zsh&arch=hurd-i386&ver=5.0.2-5&stamp=1380608100
+      manually: Your fix unfortunately seemed not to help, but another test
+      failed, too, and that one came later and was hence suspected as primary
+      failing issue.
+    <XTaran> pinotree: But "+ find: `/dev/tty': No such device or address"
+      gives some hint. I just have no idea, why find issues that message.
+    * XTaran really wonders how that message can be caused.
+    <XTaran> So find sees /dev/tty, but gets an error if it tries to access
+      (maybe only stat) it while not being connected to a terminal.
+    <XTaran> Bingo: This reproduces the issue (note the missing -t option to
+      ssh): ssh exodar.debian.net "find /dev/ -nowarn -maxdepth 1 -name 'tty*'
+      -type c -ls"
+    <XTaran> Even clearer: $  ssh exodar.debian.net "ls -l /dev/" | grep 'tty$'
+    <XTaran> ls: cannot access /dev/tty: No such device or address
+    <XTaran> ?????????? ? ?    ?       ?            ? tty
+    <XTaran> I'd say this is a bug somewhere deep down, either in libc or the
+      kernel.
+    <pinotree> or in the console translator
+    <XTaran> pinotree: Never heard of that so far. :)
+    <XTaran> pinotree: Someone from zsh upstream suggests to use /dev/null or
+      /dev/zero instead of /dev/tty* -- will try that for the next upload.
+    <pinotree> ah right, /dev/null should be standard POSIX
+    <XTaran> I hope so. :)
+    <pinotree> http://pubs.opengroup.org/onlinepubs/9699919799/ check in POSIX
+    <pinotree> in any case, sorry for the troubles it is giving you...
+    <XTaran> pinotree: I'm more concerned about the hanging second test. I
+      think I can get that test working with using /dev/null.
+    <XTaran> Now that I've understood why the original test is failing.
+    <XTaran> pinotree: Shall I write a bug report for that issue? If so,
+      against which package?
+    <pinotree> XTaran: not sure it is worth at this stage, having a clearer
+      situation on what happens could be useful
+    <pinotree> it is something that can happen sporadically, though
+    <XTaran> pinotree: Well, it seems a definitely unwanted inconsistency
+      between what the directory listing shows and which (pseudo) files are
+      accessible. Independently of where the bug resides, this needs to be
+      fixed IMHO.
+    <pinotree> sure, nobody denies that
+    <XTaran> pinotree: I'd call it easily reproducible. :)
+    <pinotree> not really
+    <XTaran> ... once you know where to look for.
diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn
index 0734e1e6..961711f3 100644
--- a/hurd/translator/mtab/discussion.mdwn
+++ b/hurd/translator/mtab/discussion.mdwn
@@ -2103,7 +2103,173 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
     <youpi> anyway, got to run
 
 
-## IRC, freenode, #hurd, 2013-09-20
+## Memory Leak
+
+Fixed in 2013-09-28 Hurd commit a81c0c28ea606b0d0a2ad5eeb74071c746b7cdeb
+(libdiskfs), and 2013-10-04 Hurd commit
+98b6f846b628e858acbae9258bac78cf54126d27 (libnetfs).
+
+### IRC, freenode, #hurd, 2013-09-18
+
+    <braunr> ext2fs is using a ginormous amount of memory on darnassus since i
+      last updated the hurd package :/
+    <braunr> i wonder if my ext2fs large store patches rework have introduced a
+      regression
+    <braunr> the order of magnitude here is around 1.5G virtual space :/
+    <braunr> it used to take up to 3 times less before that
+    <braunr> looks like my patches didn't make it into the latest hurd package
+    <braunr> teythoon: looks like there definitely is a new leak in ext2fs
+    <teythoon> :/
+    <braunr> memory only
+    <braunr> the number of ports looks stable relative to file system usage
+    <teythoon> braunr: I tested my patches on my development machine, it's up
+      for 14 days (yay libvirt :) and never encountered problems like this
+    <braunr> i've been building glibc to reach that state
+    <teythoon> hm, that's a heavy load indeed
+    <teythoon> could be the file name tracking stuff, I tried to make sure that
+      everything is freed, but I might have missed something
+    <braunr> teythoon: simply running htop run shows a slight, regular increase
+      in physical memory usage in ext2fs
+    <pinotree> old procfs stikes again? :)
+    <teythoon> braunr: I see that as well... curious...
+    <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried
+      to make sure that everything is freed, but I might have missed something
+    <braunr> how knows, maybe completely unrelated
+    <teythoon> the tracking patch isn't that big, I've gone over it twice today
+      and it still seems reasonable to me
+    <braunr> hm
+
+
+### IRC, freenode, #hurd, 2013-09-25
+
+    <braunr> seems like a small leak per file access
+    <braunr> but htop makes it obvious because it makes lots of them
+    <braunr> shouldn't be too hard to find
+    <braunr> since it might also come from the large store patch, i'll take a
+      look at it
+
+
+### IRC, freenode, #hurd, 2013-09-27
+
+    <braunr> teythoon: found the leak :)
+    <braunr> although its origin is weird
+    <teythoon> braunr: where is it?
+    <braunr> i'm still building packages to make sure that's it
+    <braunr> see
+      http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/blob/HEAD:/libdiskfs/dir-lookup.c
+    <braunr> which you changed in
+      http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/commit/06d49cdadd9e96361f3fe49b9c940b88bb869284
+    <braunr> line 306 is "return error" instead of "goto out"
+    <braunr> has been so since 1994
+    <braunr> what is unclear is why this code path is now run
+    <braunr> patch is here:
+      http://darnassus.sceen.net/~rbraun/0001-Fix-memory-leak-in-libdiskfs.patch
+    <teythoon> I see, weird indeed
+    <braunr> teythoon: the system also feels slower somehow
+    <braunr> such errors might have introduced unexpected retries
+    <teythoon> i think it's possible to write a coccinelle patch to find such
+      errors
+
+
+### IRC, freenode, #hurd, 2013-09-28
+
+    <youpi> braunr: bah, I havent noticed the leak on my box, even after
+      building eglibc & hurd several times
+    <braunr> that's weird
+    <braunr> are you sure it's up to date ?
+    <braunr> also, is procfs correctly attached to /proc ?
+    <braunr> that's what seems to trigger it
+    <youpi> yes, 20130924-2, with procfs on /proc
+
+    <teythoon> braunr: that turned out to be the leak indeed? and somehow my
+      changes triggered it? did you discover why?
+    <braunr> teythoon: yes, yes, no
+    <braunr> but youpi didn't see the leak on his system
+    <teythoon> ^^ cool that you found it
+    <teythoon> I did
+    <braunr> oh yes you mean you saw the leak
+    <teythoon> yes
+
+
+### IRC, freenode, #hurd, 2013-10-01
+
+    <braunr> the fix i did in libdiskfs might have fixed other issues
+    <braunr> apparently, it's the code path taken when error isn't ENOENT,
+      including no error (translator started)
+    <pinotree> the memory leak fix, you mean?
+    <braunr> yes
+    <braunr> it might haved fixed reference counting too
+    <braunr> although i'm not sure if we actually ever run into that issue in
+      the past
+    <braunr> the weird thing is, that path is taken when starting a passive
+      translator
+    <braunr> (i think)
+    <braunr> (it might be any kind of translator, and just doing nothing if
+      alcready active)
+    <braunr> already*
+    <braunr> anyway, the fact that the leak was so visible means this code was
+      run very often
+    <braunr> which doesn't make sense
+    <braunr> hm ok, it seems that code was run every time actually
+    <braunr> but the leak became visible when it concerned memory
+    <pinotree> which side-effects did the old code produce?
+    <braunr> teythoon added a dynamically allocated path that wasn't freed
+    <braunr> reference leaks
+    <braunr> which might explain the assertion on reference we sometimes see
+      with ext2fs
+    <braunr> when a counter overflows and becomes 0
+
+[[open_issues/ext2fs_libports_reference_counting_assertion]]?
+
+    <pinotree> hmm
+    <braunr> which is why i'm mentioning it
+    <braunr> :)
+    <braunr> i'll try to reproduce the assertion
+    <braunr> pinotree: actually, after a more in-depth look, reference counting
+      looks valid before the fix too
+    <pinotree> ok, thanks for checking
+    <braunr> pinotree: the assertion affects the root translator, and is
+      triggered by a test that stresses memory
+    <pinotree> memory as in ram, or as in disk storage?
+    <braunr> malloc
+    <pinotree> ok
+    <braunr> i suspect the code doesn't handle memory failure well
+
+
+### IRC, freenode, #hurd, 2013-10-02
+
+    <teythoon_> braunr: btw, did you fix the leak?
+    <braunr> yes
+    <braunr>
+      http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/commit/a81c0c28ea606b0d0a2ad5eeb74071c746b7cdeb
+    <braunr> 1h after tagging 0.5 (
+    <braunr> :(
+    <teythoon> ah yes, I've seen that commit
+    <teythoon> I just wanted to know whether this settled the issue
+    <braunr> it does :)
+    <teythoon> good
+    <braunr> i still can't figure out why youpi didn't had it
+    <braunr> the code path is run when no error (actually error != ENOENT)
+    <braunr> which explains why the leak was so visible
+    <teythoon> so my patch exposed this b/c of the allocation I added, makes
+      sense
+    <teythoon> it's funny actually, b/c this wasn't an issue for me as well, I
+      had my development vm running on that patches for two weeks
+
+
+### IRC, freenode, #hurd, 2013-10-02
+
+    <braunr> libnetfs suffers from the same leak as libdiskfs when looking up a
+      translator
+    <braunr> i'll fix it too
+
+
+## Multiple mtab Translators Spawned
+
+Fixed in 2013-10-05 procfs commit c87688a05a8b49479ee10127470cc60acebead4a?
+
+
+### IRC, freenode, #hurd, 2013-09-20
 
     <braunr> teythoon: how come i see three mtab translators running ?
     <braunr> 6 now oO
@@ -2113,10 +2279,231 @@ In context of [[open_issues/mig_portable_rpc_declarations]].
     <braunr> teythoon: more bug fixing for you :)
 
 
-## IRC, freenode, #hurd, 2013-09-23
+### IRC, freenode, #hurd, 2013-09-23
 
     <teythoon> so it might be a problem with either libnetfs (which afaics has
       never supported passive translator records before) or procfs, but tbh I
       haven't investigated this yet
 
 [[open_issues/libnetfs_passive_translators]].
+
+
+### [[!debbug 724868]]
+
+
+### IRC, freenode, #hurd, 2013-10-03
+
+    <braunr> i can't manage to find out where the hurd stores information about
+      active translators ...
+    <braunr> there is this transbox per node
+    <braunr> but where are nodes stored ?
+    <braunr> what if they are are dropped ?
+    <pinotree> braunr: iirc, see libfshelp
+    <braunr> well i have
+    <braunr> i still can't find it
+    <braunr> i fear that it works for ext2fs because that particular translator
+      implements a cache of open nodes
+    <braunr> whereas things like procfs drop and recreate nodes per open
+    <braunr> which would be the root cause for the multiple mtab bug
+    <pinotree> doesn't tmpfs support translators?
+    <braunr> good idea
+    <braunr> although it's still a libdiskfs based one
+    <braunr> no problem for tmpfs, so it would be a netfs/procfs issue
+    <braunr> better than what i feared :)
+    <braunr> now, how is libdiskfs able to find active translators ..
+    <braunr> ah, there is a name cache in libdiskfs ..
+    <braunr> nope, looks fine
+
+
+### IRC, freenode, #hurd, 2013-10-04
+
+    <braunr> nodes with a translator seem to keep a reference in libdiskfs and
+      not in libnetfs
+    <braunr> mhmmpf
+    <braunr> oh great ..
+    <braunr> each libdiskfs that "works" seems to implement its own
+      diskfs_cached_lookup function
+    <braunr> so both ext2fs and tmpfs actually maintain a list of nodes,
+      keeping a reference on those with a translator
+    <braunr> while procfs simply doesn't
+    <braunr> teythoon: ^
+    <braunr> *sigh*
+    <teythoon> braunr: ok, thanks, I'll look into that
+    <braunr> i'm not sure how to fix it
+    <braunr> we can either fix node destruction to cleanly shut down
+      translators
+    <braunr> but this would mean starting mtab on each access
+    <braunr> or we could implement a custom cache in procfs
+    <braunr> or perhaps a very custom change in the lookup callback for mounts
+    <braunr> i'll try the latter
+    <teythoon> err, shouldn't we try to fix this in lib*fs?
+    <braunr> unless you really want to work on it
+    <braunr> i dont' know
+    <teythoon> ah, so the node is destroyed but the translator is kept running?
+      that's what you mean by the above?
+    <teythoon> and ext2fs makes an effort of killing it in its node cleanup
+      code?
+    <braunr> yes
+    <braunr> grmbl, i'm lagging a lot
+    <braunr> i'm not sure
+    <braunr> ext2fs maintains it
+    <braunr> with ext2fs, translators can only be explicitely removed
+    <braunr> i mean, ext2fs keeps all node descriptors alive once accessed
+    <braunr> while procfs doesn't
+    <braunr> teythoon: ok, looks like i have a working patch that merely caches
+      the node for mounts
+
+    <braunr> i installed my fixed procfs on darnassus, only one mtab :)
+    <teythoon> nice :)
+
+    <braunr> i have a fix for the multiple mtab issue, will send a patch
+      tonight
+
+
+## `/home` Missing
+
+### IRC, freenode, #hurd, 2013-10-04
+
+    <braunr> now, why is there no /home in df output ?
+    <teythoon> not sure
+    <teythoon> note how /dev/tty* end up in /proc/mounts, those are passive
+      translators too, no?
+    <braunr> yes
+    <braunr> but that's a good thing i guess
+    <braunr> or was mounts intended for file systems only ?
+    <braunr> well, in the unix traditional meaning
+    <teythoon> I think its nice too, yes
+    <teythoon> but why are they fine and your /home is not...
+    <braunr> that's weirder
+    <braunr> also, mounts actually doesn't show passive translators
+    <braunr> teythoon: does your code perform any kind of comparison ?
+    <braunr> i see /servers/socket/26 but not /servers/socket/2
+    <braunr> s/comparison/filter/g
+    <teythoon> hmm
+    <teythoon> well, yes, try /hurd/mtab --insecure /
+    <teythoon> (I cannot connect to darnassus from here...)
+    <braunr> ok but that looks unrelated
+    <braunr> both /servers/socket/26 and /servers/socket/2 refer to the same
+      translator
+    <braunr> i was wondering if mtab was filtering similar entries based on
+      that
+    <teythoon> no
+    <braunr> that's weird too then, isn't it ?
+    <teythoon> yes ;)
+    <braunr> ok
+    <teythoon> btw, how is that done with the same traanslator being bound to
+      two nodes? settrans cannot do that, can it?
+    <braunr> no it can't
+    <braunr> the translator does it when started
+    <teythoon> ah
+    <braunr> (which means there is a race if both are started simulatneously,
+      although it's very rare and not hard to solve)
+    <teythoon> a weird beaving translator then :)
+
+    <braunr> teythoon: if ext2fs is set active, mtab output reports it
+
+    <braunr> teythoon: looks like this bug is what allows mtab not to deadlock
+    <braunr> teythoon: when i attach it as an active translator, cat freezes
+
+    <braunr> teythoon: if (control && control->pi.port_right == fsys)
+    <braunr> that's the filtering i was previously talking about
+
+    <braunr> oh please don't name global variables "path" ...
+
+
+### IRC, freenode, #hurd, 2013-10-06
+
+    <antrik> teythoon: pty-s also bind to two nodes, not only pfinet
+
+
+### IRC, freenode, #hurd, 2013-10-07
+
+    <braunr> teythoon: please tell us when you're available, we need to work
+      out the last mtab issues
+    <teythoon> braunr: I'm available now :)
+    <teythoon> I'm sorry, I've been very busy the last two weeks, but I've
+      plenty of time now
+    <braunr> great :)
+    <braunr> did you see youpi's mail ?
+    <braunr> i have the exact same question
+    <teythoon> I did
+    <braunr> it seems your code registers active translators
+    <braunr> but parent translators don't seem to register them when they're
+      created from passive translators
+    <braunr> or am i mistaken ?
+    <teythoon> I'll need a moment to get my hurd machine and myself up to
+      speed...
+    <teythoon> braunr: I concur with youpi, hooking into fshelp_fetch_root
+      should do just fine
+    <teythoon> I'll just try that
+    <braunr> ok
+    <braunr> how do you deal with mtab reporting itself ?
+    <teythoon> o_O does it do that?
+    <braunr> no, but it should
+    <braunr> when i set it as an active translator, i get a deadlock
+    <braunr> hm
+    <braunr> teythoon: before you change libfshelp, i'd like you to try
+      something else
+    <braunr> use more appropriate names for global variables in mtab.c
+    <braunr> in particular, the variable path clashes with local names
+    <teythoon> noted
+    <braunr> teythoon: as a side note (i'm not asking to rewrite anything)
+    <braunr> i strongly recommend a very explicit object oriented style of
+      coding
+    <braunr> (or data-oriented as it's sometimes called)
+    <braunr> use prefixes for all your interfaces so they can be made public if
+      needed (which acts as a namespace and avoids lots of collisions
+      naturally)
+    <braunr> use "constructors" and "destructors" (functions that both allocate
+      and initialize)
+    <braunr> this helps avoiding leaks a lot too
+    <teythoon> hm, I thought I did that, could you be more specific?
+    <braunr> ok didn't see the comment
+    <braunr> /* XXX split up */ error_t mtab_populate (...
+    <braunr> :)
+    <braunr> as a better example, see your code in libfshelp/translator-list.c
+    <braunr> struct translator should have been treated as an object
+    <braunr> this would probably have completely avoided any leaks in the first
+      place
+    <teythoon> braunr: right, I deviated from that style there
+    <braunr> teythoon: these are minor details, don't mind them too much, i
+      just find it helps me a lot
+    <teythoon> braunr: sure, I appreciate the feedback :)
+
+
+### IRC, freenode, #hurd, 2013-10-08
+
+    <teythoon> braunr: I'm on to the passive translator not getting registered
+      issue
+    <teythoon> however, removing them from the list if the active translator is
+      killed does not work as expected... I still need to fiddle with the
+      notifications to get this right
+    <braunr> ok
+
+
+### IRC, freenode, #hurd, 2013-10-16
+
+    <teythoon> braunr: btw, I fixed the 'passive translator not showing up in
+      proc/mounts'-issue
+    <teythoon> but 4 ports do leak each time a translator is killed and
+      reinstalled
+    <teythoon> this happens with passive ones as well as active ones
+    <braunr> teythoon: is that issue tied to your changed ?
+    <braunr> changes*
+    <teythoon> I'm not sure tbh, testing that is on my list of things to do
+    <braunr> ok
+    <braunr> first thing to know i guess
+    <teythoon> yes
+
+
+## Memory Leak in `translator_ihash_cleanup`
+
+### IRC, freenode, #hurd, 2013-10-04
+
+    <braunr> teythoon: isn't there a leak in translator_ihash_cleanup ?
+    <teythoon> braunr: looks like, yes
+    <teythoon> braunr: I probably forgot to add the free (element->name) when I
+      added the name field
+    <braunr> teythoon: ok
+    <braunr> teythoon: i let you fix that :p
+    <teythoon> braunr: sure ;)
diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn
index d5e0960c..b3b5e703 100644
--- a/hurd/translator/proc.mdwn
+++ b/hurd/translator/proc.mdwn
@@ -63,6 +63,11 @@ It is stated by `/hurd/init`.
       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
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index fc071337..87ff0248 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -436,6 +436,72 @@ 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`>  
+    <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
+
+
 # `/proc/[PID]/mem`
 
 Needed by glibc's `pldd` tool (commit
@@ -471,3 +537,56 @@ Needed by glibc's `pldd` tool (commit
 
     <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
+      enough
+    <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
+      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-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
diff --git a/hurd/translator/term.mdwn b/hurd/translator/term.mdwn
new file mode 100644
index 00000000..78c83276
--- /dev/null
+++ b/hurd/translator/term.mdwn
@@ -0,0 +1,214 @@
+[[!meta copyright="Copyright © 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 *term* translator implements POSIX termios discipline.
+
+
+# Open Issues
+
+## [[open_issues/Term_Blocking]]
+
+## Leaks/Not Re-used/Not Terminating
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-10-14
+
+    <braunr> good news
+    <braunr> the terminal leak is related to privilege separation
+
+[[tschwinge]] confirming (using `ssh -t [machine] tty`) that with privilege
+separation enabled there is this problem, and once disabled it goes away.
+
+    <atheia> I love how, as an unknowing by-stander, that is somehow good news
+      :-)
+    <braunr> :)
+    <braunr> it's a good news because 1/ we have more knowledge about the issue
+    <braunr> and 2/ it may not even be a hurd bug
+    <braunr> but rather an openssh-on-hurd bug
+    <braunr> this explains why i didn't see the issue on anything else
+      (mach/hurd consoles, x terminals)
+    <braunr> and this will also indirectly solve the screen lockup issue
+    <teythoon> braunr: good catch :)
+    <braunr> s/a good news/good news/
+    <atheia> ah, yes, both definitely good news. Congrats on the progress.
+    <braunr> i remember we used to disable privilege separation in the past
+    <braunr> i'll have to dig what made us use it
+
+[[news/2010-09]].
+
+    <braunr> interesting, screen seems to be affected nonetheless
+    <braunr> so it's something common to both screen and ssh privsep
+    <braunr> apparently, what sshd+privse and screen have in common is a fifo
+    <braunr> so it's probably a tricky hurd bug actually
+
+
+### IRC, freenode, #hurd, 2013-10-16
+
+    <braunr> pflocal is leaking ports ..
+    <braunr> this might be what blocks terminals
+    * pinotree gives braunr a stick of glue
+    <braunr> thanks
+
+    <braunr> pflocal leaks struct sock ..
+    <braunr> grmbl
+
+    <braunr> hm nice, pflocal leaks each time a socket is bound and/or accepted
+      on
+    <braunr> looks like a simple ref mess
+    <pinotree> braunr: really?
+    <braunr> yes
+    <pinotree> a leak in pflocal feels strange, never noticed it taking lots of
+      memory (and it's used a lot)
+    <braunr> it's a port leak
+    <braunr> well
+    <braunr> no it's both a memory and port leak
+    <braunr> not sure which one is the root cause yet
+    <braunr> i guess server sockets aren't automatically unbound
+    <braunr> if you want to see the leak, just disable priv separation in ssh
+      (to avoid the terminal leak ....) and write a shell loop to start ssh
+      your_server echo hello
+    <braunr> google shows mails about the leak in the past
+    <braunr> i also hope it fixes the terminal leak, although i'm really not
+      sure :(
+
+
+### IRC, freenode, #hurd, 2013-10-17
+
+    <braunr> hm nice, apparently, there is no pflocal leak
+    <braunr> but a libdiskfs one !
+    <braunr> since ext2fs enables the ifsock shortcut
+    <braunr> seems like it leaks a reference on sock node deletion
+    <teythoon> braunr: have you looked at libdiskfs/dead-name.c?
+    <teythoon> braunr: I think I'm hunting a very similar problem
+    <braunr> i'm doing it now
+    <teythoon> I had the problem of dead name notifications not being delivered
+    <braunr> wow
+    <teythoon> b/c I held no reference to the ports_info thing, so the dead
+      name handler in libports could no longer find the pi struct, so the
+      notification was silently dropped
+    <braunr> i see
+    <braunr> but it looks like dropping a node makes sure the associated
+      sockaddr has been deleted if any
+    <teythoon> are you sure the node is dropped in the first place?
+    <braunr> no
+    <braunr> well
+    <braunr> i see something happenning at the pflocal side when removing the
+      node
+    <braunr> but there is still a send right lingering somewhere
+    <braunr> (see why we need a global lsof :p)
+    <teythoon> indeed
+    <braunr> i'll try portinfo with that option we talked about
+    <teythoon> yes
+    <braunr>    121 =>   1682: send (refs: 1)
+    <braunr> yep, ext2fs still has it
+    <teythoon> (I wonder how portinfo does that...)
+    <braunr> i guess it imports rights from the target task
+    <braunr> and see if it gets the same name as a local right
+    <teythoon> makes sense
+    <braunr> easy to check
+    <teythoon> well, no, it cannot do that for receive rights
+    <braunr> it creates an empty task just for that purpose
+    <braunr> and uses mach_port_extract_right
+    <teythoon> but it works as you described, yes
+    <braunr> so yes it does work for receive rights too
+    <teythoon> yes
+    <teythoon> cool :)
+    <braunr> so it assumes identical port names are part of the ipc interface
+    <braunr> something neal said we shouldn't rely on
+    <braunr> iirc
+    <teythoon> yes, I remember something like that too
+    <braunr> here is the strange thing
+    <braunr> node->sockaddr is deallocated on a dead name notification
+    <braunr> drop_node checks that sockaddr is null
+    <braunr> so how can the dead name notification occur before the node is
+      dropped ?
+    <braunr> so maybe the node is still around indeed
+    <braunr> apparently, libdiskfs considers the address holds a reference on
+      the node
+    <braunr> on the other hand, the server socket won't get released unless the
+      address gets a no-sender notification ...
+    <braunr> this should probably be turned into a weak reference
+    <braunr> teythoon: indeed, the node is leaked
+
+    <braunr> pflocal crashes when removing correctly deallocating addresses and
+      removing server sockets :/
+
+    <braunr> ok, pflocal bug fixed
+    <braunr> still have to fix the libdiskfs leak
+    <braunr> and libdiskfs leak fixed too
+    <braunr> :)
+    <braunr> i'll build hurd packages with my changes to make sure i don't
+      break something before comitting
+    <braunr> and see if this fixes the term issue
+
+    <braunr> looks like my patches work just fine :)
+    <braunr> it doesn't solve the term issue though
+
+    <braunr> so, according to portinfo, pflocal has send rights to terminals oO
+
+    <braunr> mhhhmmmmmm
+    <braunr> openssh seems to pass terminal file descriptors through unix
+      sockets when using privilege separation
+    <pinotree> braunr: i a write(sock, &pid, sizeof int) (or the like)?
+    <pinotree> *ie
+    <braunr> not pid, file descriptors
+    <braunr> SCM_RIGHTS
+    <pinotree> ah ok
+    <braunr> the socket send/recv interface does support passing mach ports
+    <braunr> and the leaked ports do turn into dead names when i kill terminals
+    <pinotree> yes, we support with a patch pochu did few years ago
+    <braunr> so it seems the leak is related to libpipe this time
+    <braunr> ok got it :)
+    <braunr> pflocal used copy_send instead of move_send
+    <braunr> \o/
+    <braunr> that bug was such a pain
+    * braunr happy
+    <teythoon> :)
+    <pinotree> speaking of it, in pflocal' S_socket_recv is it correct the
+      "out_flags = 0;"?
+    <braunr> nice catch
+    <braunr> although i wonder why flags are returned
+    <braunr> it may have been set to null to tell us that we don't want to
+      return flags
+    <braunr> pfinet seems to use it
+    <pinotree> but you change a local variable anyway
+    <braunr> yes it's not useful
+    <braunr> hmm
+    <braunr> out_flags is what gets in struct msghdr -> msg_flags
+    <braunr> so i guess it makes sense to fix it to *out_flags = 0, just to be
+      safe
+    <braunr> pinotree: do you want me to push it tonight along with the others
+      ?
+    <pinotree> yes please
+    <braunr> ok
+    <pinotree> thanks!
+    <braunr> pflocal seems to not leak any memory or ports at all
+    <braunr> great :>
+
+    <braunr> there, patches pushed :)
+
+
+## `screen` Logout Hang
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-10-14
+
+    <braunr> i fixed term so that screen can shutdown properly
+    <braunr> read() wouldn't return EIO after terminal hangup
+
+
+### IRC, freenode, #hurd, 2013-10-17
+
+    <braunr> and the missing EOI prevented screen from correctly shutting down
+      windows
diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn
index 20aba837..8c332d84 100644
--- a/hurd/translator/tmpfs/discussion.mdwn
+++ b/hurd/translator/tmpfs/discussion.mdwn
@@ -430,3 +430,40 @@ License|/fdl]]."]]"""]]
     <youpi> ok
     <youpi> but that indeed means writeback of ext2fs works, which is a good
       sign :)
+
+
+# IRC, freenode, #hurd, 2013-10-04
+
+    <teythoon> btw, I noticed that fifos do not work on tmpfs
+    <braunr> teythoon: tmpfs seems limited, yes
+    <teythoon> that's annoying b/c /run is a tmpfs on Debian and sysvinit
+      creates a crontrol fifo there
+    <teythoon> I wonder why I didn't notice that before
+    <braunr> also, fifos, like symlinks, can be shortcircuited in libdiskfs
+    <braunr> i wonder if that has anything to do with the problem at hand
+
+[[mtab/discussion]], *Multiple mtab Translators Spawned*.
+
+    <teythoon> b/c this breaks reboot & friends
+    <teythoon> I do too
+    <teythoon> b/c I cannot find any shortcut related code in tmpfs
+    <braunr> well, it's optional normally
+    <braunr> so that's ok
+    <braunr> but has it really been tested when the option wasn't there ? :)
+    <teythoon> yes, but the tmpfs requests this by setting diskfs_shortcut_fifo
+      = 1;
+    <pinotree> hm i remember tmpfs was said to be working with
+      sockets/fifos/etc, back then when it was fixed
+    <braunr> teythoon: oh
+
+
+## IRC, freenode, #hurd, 2013-10-11
+
+    <teythoon> this will have to wait for the next hurd pkg unfortunately, b/c
+      I broke tmpfs by accident :-/
+    <pinotree> how so?
+    <teythoon> the dropping of privileges broke passive translators and mkfifo
+    <braunr> there actually is a reason why those are run as root or with the
+      privilege of their owner
+    <braunr> privileges should be decoupled from identity
+    <teythoon> yes
author	Thomas Schwinge <thomas@codesourcery.com>	2014-02-26 12:43:40 +0100
committer	Thomas Schwinge <thomas@codesourcery.com>	2014-02-26 12:43:40 +0100
commit	ca63bd2d33b3d28eabd50ad58577b52a1fc9eba0 (patch)
tree	74bf46806011262f116d83ff5bec0a1cf8a79a4b /hurd
parent	5757d0c3b11dac706fbe72247e9d2dcf0ff44df9 (diff)
parent	7ffc398e1c386925826c42a30ff10ae84e79378f (diff)