From mboxrd@z Thu Jan 1 00:00:00 1970 From: Serge Hallyn Subject: Re: Virtualizing /proc/sys/kernel/random/boot_id per container ? Date: Tue, 4 Sep 2012 09:44:28 -0500 Message-ID: <20120904144428.GB14093@amd1> References: <20120830211832.GA3297@redhat.com> <878vcwjabu.fsf@xmission.com> <20120830225002.GA9226@redhat.com> <87bohrhqai.fsf@xmission.com> <5044629C.3030909@parallels.com> <87r4qi6g6k.fsf@xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <87r4qi6g6k.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: "Eric W. Biederman" Cc: containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org List-Id: containers.vger.kernel.org Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org): > Glauber Costa writes: > > > On 08/31/2012 04:13 AM, Eric W. Biederman wrote: > >> "Daniel P. Berrange" writes: > >> > >>> On Thu, Aug 30, 2012 at 03:15:17PM -0700, Eric W. Biederman wrote: > >>>> "Daniel P. Berrange" 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. > >>> > >>> SystemD records log messages for all system services in their journal. > >>> They can show you all log messages for the current service execution, > >>> all log messages for a service since system boot, or all log messsages > >>> ever. The boot_id value is used as a unique tag to allow grouping of > >>> the log messages per system boot. When we run systemd inside a container > >>> we want to get that grouping of log messages generated by services inside > >>> the container, to take account of the container boot, not the host boot. > >>> Hence the desire to have the boot_id value reflect when a container is > >>> booted. > >> > >> Since SystemD post-dates containers and since the logging feature is not > >> currently in wide use that use case is completely non-persuasive. > >> > >> So far this just sounds like a plain SystemD bug and something that can > >> be easily changed at this point in time. > >> > >> It has been a long time but my fuzzy memory says that the originial > >> boot_id justification was based on use cases that could not be solved > >> any other way. > >> > >> My memory says it was this thread https://lkml.org/lkml/1999/5/31/233 > >> that inspired the implementation of boot_id. However reading the > >> current emacs source code it appears emacs gave up before boot_id > >> was implemented and stats /var/run/random-seed (which we seem to > >> have removed) or looks in wtmp or utmp for the latest boot record. > >> > >> I did a quick grep through the binaries on my system and I could not > >> find anything using /proc/sys/random/boot_id. > >> > >> That suggests to me that the proper solution is to actually just remove > >> boot_id. > >> > >> Hmm. And then there is other interesting detail. What should boot_id > >> return after the processes have migrated from one system to another. > >> > > > > Since this would be a per-boot id, this clearly has to be carried over > > with migration, along with all the tons of data we already carry. > > The twist of course is what does a boot mean. If we are really after > machine boots than the current behavior is correct. > > Looking back in the archives the desired behavior appears to be a value > that can be used to see if a pid value must be stale. > > As a stale pid detector boot_id is pretty lousy. Pids can still be > reused. > > Still a role as a stale pid detector makes it clear which namespace > boot_id should be in and how we should treat boot_id upon migration. > > You can only serve as a stale pid detector if you are in the pid > namespace. > > So at this point patches are welcome. Hopefully with a summary > of the discussion. I don't understand why this should be provided by the kernel. Especially given that we've proven that everyone really wants this to be per-container as well. So why not just have init, on startup, create a /run/boot_id file, perhaps by sha1summing the time at which it started perhaps plus some nonce?