idk, seems kinda something we don't want to change

there is a golib for keyctl that is pretty nice https://github.com/jsipprell/keyctl

is someone actually using this and hitting the quota?

imo this feature is causing more pain than its worth, like the whole keyctl session in runc thing, but just throwing it out there, carry on :)

</exits>

AFAICT we either need to:

1. have runc automatically update the limits
2. tell admins that they need to think about this if they want to run more than a couple of hundreds (seems to be the default on ubuntu at least)
3. revert Create unique session key name for every container #582
4. ??

I'm not a huge fan of 2.

As for 3, reverting it would basically let any container see the keys of every other containers.

Anyone got a number 4?

So the thing is I can see the key ids and key users of other containers and
the host with #582, IANAM but 4 sounds good to me :P

On Wed, Apr 6, 2016 at 8:17 PM, Kenfe-Mickaël Laventure <
[email protected]> wrote:

AFAICT we either need to:

1. have runc automatically update the limits
2. tell admins that they need to think about this if they want to run
   more than a couple of hundreds (seems to be the default on ubuntu at least)
3. revert Create unique session key name for every container #582 Create unique session key name for every container #582
4. ??

I'm not a huge fan of 2.

As for 3, reverting it would basically let any container see the keys of
every other containers.

Anyone got a number 4?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#727 (comment)

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3

Why doesn't containerd deal with this? I don't think we should aggressively increase limits that have (presumably) been set by an administrator. People might be using runc as a separate utility, and it should error out if the quota has been exceeded. containerd should deal with this (make sure the quota is big enough for the number of containers it's managing) and have options to cap it and things like that. Speaking of which, is there any plan to get a proper config file for containerd set up?

I think this should be dealt at a higher level. Or even just a message could be printed by docker/containerd when it is started warning the admin about the limit.
For e.g. redis server does something similar when it is started up.

1:C 07 Apr 16:44:55.965 # Warning: no config file specified, using the default config. In order to specify a config file use /usr/bin/redis-server /path/to/redis.conf
1:M 07 Apr 16:44:55.968 # You requested maxclients of 10000 requiring at least 10032 max file descriptors.
1:M 07 Apr 16:44:55.968 # Redis can't set maximum open files to 10032 because of OS error: Operation not permitted.
1:M 07 Apr 16:44:55.968 # Current maximum open files is 1024. maxclients has been reduced to 992 to compensate for low ulimit. If you need higher maxclients increase 'ulimit -n'.
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 3.0.6 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                   
 (    '      ,       .-`  | `,    )     Running in standalone mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
 |    `-._   `._    /     _.-'    |     PID: 1
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           http://redis.io        
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

1:M 07 Apr 16:44:55.969 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

+1 for moving this to upper layer.

@mrunalp i dont think we want to print the warning when we can start the container ( to not polluting the stream ). But catching EDQUOT and print out a more human-friendly error is fine i think.

@dqminh I was suggesting that the daemon (either docker/containerd) print this in its logs on startup, not when it is trying to launch a container or in runc.

containerd would only be aware of this once runc fails to start the container due to an EDQUOT error atm. It could always be updated to check the quota value upon startup but in that case runc documentation should make it explicit that this is expected to be done by something/someone else than itself.

@mlaventure

I still feel that this is something that shouldn't be automatically done by runC. runC's job is to start one container, so it doesn't make sense (to me) that runC should start increasing system limits because it can't start said container. runC shouldn't assume that's what a user of runC wants (maybe containerd would like that to happen, but containerd is not the only user of runC).

My suggestion is to make containerd set a particular quota (or dynamically change it) based on options that the sysadmin has provided. Or, as you said, we can make it so that containerd will resize it automatically if runC fails (but that feels like a bad way of solving the problem).

Hum, I see your point. I guess it makes sense.

I'll move this up to containerd when I'm back from my pto then.

On Fri, Apr 8, 2016, 5:51 PM Aleksa Sarai [email protected] wrote:

@mlaventure https://github.com/mlaventure

I feel like this is still something that shouldn't be automatically done
by runC. runC's job is to start one container, so it doesn't make sense
(to me) that runC should start increasing system limits because it can't
start said container. runC shouldn't assume that's what a user of runC
wants (maybe containerd would like that to happen, but containerd is not
the only user of runC).

My suggestion is to make containerd set a particular quota (or dynamically
change it) based on options that the sysadmin has provided. Or, as you
said, we can make it so that containerd will resize it automatically if
runC fails (but that feels like a bad way of solving the problem).

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#727 (comment)