[OE-core] [PATCH] glibc-locale: Rewrite do_install using install utility instead of cp
Richard Purdie
richard.purdie at linuxfoundation.org
Thu Feb 7 17:21:38 UTC 2019
On Thu, 2019-02-07 at 10:59 -0600, Joshua Watt wrote:
> On Thu, Feb 7, 2019 at 10:44 AM Joshua Watt <jpewhacker at gmail.com>
> wrote:
> > Martin,
> >
> > Do you by any chance build in Docker (or some other transient
> > container)? We recently found an issue with building in docker
> > where when the primary container command would exit, causing the
> > container to terminate. When the container terminates, the kernel
> > unceremoniously sends SIGKILL to all its processes. This plays
> > *very* poorly with pseudo because pseudo keeps it's entire database
> > in a in-memory sqlite database and only flushes it out to disk on a
> > periodic interval, or when it get SIGTERM (maybe SIGQUIT?) or exits
> > normally. By default the pseudo daemon will also hang around for
> > 20(?) seconds waiting for a new connection from a pseudo client,
> > meaning that when our docker container was exiting, there were
> > potentially several pseudo dameons sitting around waiting for a
> > client with unflushed databases in memory that suddenly got a
> > SIGKILL and all their data was lost. This was particularly bad if
> > you aborted a build while it was running, or some build failure
> > occurred. Since
> the pseudo database was lost, the only way to correct these errors
> was to clean and rebuild.
> > I think pseudo could handle this better and keep the database on
> > disk instead of in memory, but in the short term you can hack
> > bitbake to pass the -S flag when invoking the pseudo client which
> > will make it tell the dameon to shutdown (and thus flush the
> > database) if it is the last connection.
>
> FWIW, this patch makes it much easier to do that
> http://lists.openembedded.org/pipermail/bitbake-devel/2019-February/019813.html
> Just add
> FAKEROOTCMD += "-S"
> in local.conf
Should we be doing that by default? Is there a downside?
Keeping the database flushed to disk would likely be slow but this
seems reasonable.
Cheers,
Richard
More information about the Openembedded-core
mailing list