3 ms·

Is there an easy way to duplicate a specific process' namespace? My biggest issue with all these new features is that privatize state is how much harder it is

Is there an easy way to duplicate a specific process' namespace? My biggest issue with all these new features is that privatize state is how much harder it is to reproduce a state. Back when it was just environment variables, I could pipe /proc/PID/environ to xargs and get basically the same state. Given that things like unix domain sockets may end up in $TMPDIR, I can be left unable to do certain things.

zbentley 2y ago
I don't think there is, or should be, a way to do that. Granular copying of per-process resource state seems like a need that would be better served at either a closer-to-the-program layer (i.e. debug hooks in code you control that provide information on how to reconstruct its state) or much further away (e.g. via CRIU/whole-machine snapshots or scary tricks like SIGSTP or ptrace-injecting calls to fork(2)). > I can be left unable to do certain things Most of what I can imagine of "certain things" falls into two categories: debugging (for which much better tools exist), or concerns that would be better served by a program providing an API of some kind rather than "go muck with state in $TMPDIR".
- aidenn0 2y ago
  Here's a recent one; I needed to play some sound via an ssh login session. A Wayland/pipewire session was already open. I was able to do this just by copying a running processes environment. With enough containerization &c. I'll need to do more things to do that, if it's at all possible. Also, /proc/ is (among other things) a debug interface.
xerxes901 2y ago
/proc/PID/root is a view of that process’s mount namespace. Also you can use nsenter(8) to run a command (or even a shell) under another process’s mount, pid, network, etc namespace.
- aidenn0 2y ago
  Thanks! It's exactly what I was looking for, and the world can now continue to improve without breaking any of my workflows :)
- zokier 2y ago
  mount namespace and root directory are bit different things though. /proc/$PID/ns is the place to look for namespaces
zokier 2y ago
nsenter --all --target $PID or something like that? https://man7.org/linux/man-pages/man1/nsenter.1.html https://man7.org/linux/man-pages/man1/nsenter.1.html

zbentley 2y ago

I don't think there is, or should be, a way to do that. Granular copying of per-process resource state seems like a need that would be better served at either a closer-to-the-program layer (i.e. debug hooks in code you control that provide information on how to reconstruct its state) or much further away (e.g. via CRIU/whole-machine snapshots or scary tricks like SIGSTP or ptrace-injecting calls to fork(2)). > I can be left unable to do certain things Most of what I can imagine of "certain things" falls into two categories: debugging (for which much better tools exist), or concerns that would be better served by a program providing an API of some kind rather than "go muck with state in $TMPDIR".

aidenn0 2y ago
Here's a recent one; I needed to play some sound via an ssh login session. A Wayland/pipewire session was already open. I was able to do this just by copying a running processes environment. With enough containerization &c. I'll need to do more things to do that, if it's at all possible. Also, /proc/ is (among other things) a debug interface.

xerxes901 2y ago

/proc/PID/root is a view of that process’s mount namespace. Also you can use nsenter(8) to run a command (or even a shell) under another process’s mount, pid, network, etc namespace.

aidenn0 2y ago
Thanks! It's exactly what I was looking for, and the world can now continue to improve without breaking any of my workflows :)
zokier 2y ago
mount namespace and root directory are bit different things though. /proc/$PID/ns is the place to look for namespaces

zokier 2y ago

nsenter --all --target $PID or something like that? https://man7.org/linux/man-pages/man1/nsenter.1.html https://man7.org/linux/man-pages/man1/nsenter.1.html