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. -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
