Quoting Glauber Costa (glommer@xxxxxxxxxxxxx): > On 08/31/2012 05:25 PM, Serge Hallyn wrote: > > Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > >> "Daniel P. Berrange" <berrange@xxxxxxxxxx> writes: > >> > >>> One of the features that SystemD folks have asked us to fix in LXC, is > >>> to make sure that /proc/sys/kernel/random/boot_id changes each time a > >>> container is started. > >> > >> There may be a good reason for this. Most of the time what I have seen > >> of kernel requests from the direction of SystemD is that while there may > >> be a real problem but usually their imagined solution is not a > >> particularly good solution. So a description of the problem is needed. > >> > >> Justifying something with just SystemD wants this is a good way to get > >> a nack. > >> > >>> The current semantics are that this file produces a new random UUID each > >>> time the host OS is booted. Obviously each time we start a container now, > >>> they just see the host's random boot_id, so from a container's POV this > >>> does not change each time it starts. > >> > >> That is correct. As I recall the contract with boot_id is to provide > >> a unique per boot value to assist in dealing with boots etc. I seem > >> to recall emacs uses the combination of hostname+boot_id to help > >> generate unique lock files names. > >> > >> I would definitely need a refresher on how boot_id is used in practice > >> by applications other than SystemD before I could suggest a good design. > >> > >> There is also a question of uptime. > >> > >>> There seems to be general agreement that, aside from the PID directories, > >>> changes to data in proc should be done by a FUSE filesystem overlay of > >>> some kind. > >> > >> No. I have yet to see a justification for using FUSE in containers on > >> top of proc files. > >> > >> I have seen a lot of bad ideas suggested like hacking /proc/cpuinfo > >> instead of providing a proper mechanism to tell applications how > >> parallel they can/should be. > > > > Should we be talking about a new set of library functions to gather info > > like available memory and cpus, etc? The library functions could internally > > take into account the per-host procfiles, cgroup info, and, as the need > > arises, new sources of information. > > > > I think this makes a lot of sense. Cool. I can't do it today, but it might be worth starting a list (on wiki?) of information userspace wants (uptime, cpuinfo, meminfo, etc) so we can come up with a reasonable api. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
