9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: mycroftiv@sphericalharmony.com
To: 9fans@9fans.net
Subject: [9fans] namespace repair via /proc
Date: Tue, 12 Mar 2013 14:36:16 +0000	[thread overview]
Message-ID: <5ca9a0f41f6f0c7263ecc50bec2cb563@sphericalharmony.com> (raw)

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"



                 reply	other threads:[~2013-03-12 14:36 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5ca9a0f41f6f0c7263ecc50bec2cb563@sphericalharmony.com \
    --to=mycroftiv@sphericalharmony.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).