From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <5ca9a0f41f6f0c7263ecc50bec2cb563@sphericalharmony.com>
Date: Tue, 12 Mar 2013 14:36:16 +0000
From: mycroftiv@sphericalharmony.com
To: 9fans@9fans.net
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] namespace repair via /proc
Topicbox-Message-UUID: 27c04394-ead8-11e9-9d60-3106f5b1d025

sl wrote:
> I can see a use for this in re-inserting broken mounts
> higher up in the proc tree.

Yes, general "namespace repair" is one of the things I use the
writable /proc/pid/ns mechanism for a lot.  Especially the fact that
you can apply these operations to remote systems via import of /proc
can help keep a grid of machines working together smoothly if you need
namespace adjustments to fix something or acquire a new resource.  One
application I have only worked on only in the most direct form (cpns,
addns, subns) is that scripts can apply extensive namespace
transformations to an arbitarary number of target processes.  In
theory - and note the "theory" here for this - you could make a
'fixns' cronjob that tested to make sure mounted stuff on the network
was still answering, and if it wasnt, it could remove the dead files
in /srv, redial, and then use namespace injection to repair things
as much as possible.

Even though I do some of this now by hand, I have run into one
practical obstacle that limits what can be fixed in this way.  It's a
consequence of something which is important for making the ns
rewriting work at all.  Rewriting the namespace of a process does not
affect the open file descriptors.  Once a file descriptor is opened,
changing the namespace won't break it.  This is actually a very good
thing for making namespace injection via /proc usable and not horribly
broken as a practical matter.  You can freely rewrite the namespace of
running processes without corrupting the files they are currently
reading and writing to,  so it is very good it works this way.
However, in the case of some server processes (an example is /srv/cs
and the /lib/ndb/local file) the fact that the process maintains an
open file descriptor to the file means that you can't use ns mod to
re-connect a /srv/cs to a different /lib/ndb/local file.

In practice whether the repair you need to do is on a process that has
open fds that can't be fixed doesn't have a general answer in my
experience at least.  Some things fix up nicely but with others, since
they are attached to a dead fd and not letting go, changing the ns
doesn't help.  I've actually thought enough about this that I've
wondered what more could be done with the file descriptors and
underlying chans to let you do even more to repair and modify what
running processes are reading and writing from.

All of that said, I can confirm that /proc namespace injection on
arbitrary processes does let you fix or workaround some issues that
can arise with Plan 9 networks and needing to connect new mounts or
reacquire/shift attachment to older ones.

Ben Kidwell
"mycroftiv"