From: Marian Marinov <mm@1h.com>
To: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
LXC development mailing-list
<lxc-devel@lists.linuxcontainers.org>,
Linux Containers <containers@lists.linux-foundation.org>
Subject: [RFC] Per-user namespace process accounting
Date: Thu, 29 May 2014 09:37:01 +0300 [thread overview]
Message-ID: <5386D58D.2080809@1h.com> (raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I have the following proposition.
Number of currently running processes is accounted at the root user namespace. The problem I'm facing is that multiple
containers in different user namespaces share the process counters.
So if containerX runs 100 with UID 99, containerY should have NPROC limit of above 100 in order to execute any
processes with ist own UID 99.
I know that some of you will tell me that I should not provision all of my containers with the same UID/GID maps, but
this brings another problem.
We are provisioning the containers from a template. The template has a lot of files 500k and more. And chowning these
causes a lot of I/O and also slows down provisioning considerably.
The other problem is that when we migrate one container from one host machine to another the IDs may be already in use
on the new machine and we need to chown all the files again.
Finally if we use different UID/GID maps we can not do live migration to another node because the UIDs may be already
in use.
So I'm proposing one hack modifying unshare_userns() to allocate new user_struct for the cred that is created for the
first task creating the user_ns and free it in exit_creds().
Can you please comment on that?
Or suggest a better solution?
Best regards,
Marian
- --
Marian Marinov
Founder & CEO of 1H Ltd.
Jabber/GTalk: hackman@jabber.org
ICQ: 7556201
Mobile: +359 886 660 270
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iEYEARECAAYFAlOG1Y0ACgkQ4mt9JeIbjJQREACbBrax+ztBj2Y0P2jY3qYEUY9T
JJ0AnAqLj3pqFFjXCkczEydV1V0LdzQ3
=8M+P
-----END PGP SIGNATURE-----
next reply other threads:[~2014-05-29 6:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-29 6:37 Marian Marinov [this message]
2014-05-29 10:06 ` [RFC] Per-user namespace process accounting Eric W. Biederman
2014-05-29 10:40 ` Marian Marinov
2014-05-29 15:32 ` Serge Hallyn
2014-06-03 17:01 ` Pavel Emelyanov
2014-06-03 17:26 ` Serge Hallyn
2014-06-03 17:39 ` Pavel Emelyanov
2014-06-03 17:47 ` Serge Hallyn
2014-06-03 18:18 ` Eric W. Biederman
2014-06-03 17:54 ` Eric W. Biederman
2014-06-03 21:39 ` Marian Marinov
2014-06-23 4:07 ` Serge E. Hallyn
2014-06-07 21:39 ` James Bottomley
2014-06-08 3:25 ` Eric W. Biederman
2014-06-12 14:37 ` Alin Dobre
2014-06-12 15:08 ` [lxc-devel] " Serge Hallyn
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=5386D58D.2080809@1h.com \
--to=mm@1h.com \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lxc-devel@lists.linuxcontainers.org \
/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