At the end of bitbake selftest we see:
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' mode='r+' encoding='UTF-8'>
Clean up the /dev/null handling to drop the unused entry in build.by and
ensure the other open() calls are cleaned up.
NULL was unused since http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/build.py?id=4a081b5a52e3d27da8d4b062f3fda292e8d8fb0a
back in 2012.
(Bitbake rev: e72be96cfa9f05fda5f420c7cfa8bcfa9304b884)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There were various problems in the server startup loggin:
a) stdout/stderr were not being flushed before forking which could potentially
duplicate output
b) there were separate buffers for stdout/stderr leading to confusing logs
where the entries could be reordered. This was particularly confusing
due to the separator the logs use to idendify new messages
c) an fd wasn't being closed during server startup meaning if the
server failed to start, the closed fd wasn't detected as it was held
open by the other reference
d) If the pipe was detected as being closed, the code incorrectly retried
server startup
e) The event code would remap stdout/stderr without flushing them, leading
to lose log messages
(Bitbake rev: 0594faa0b52ce5dbd948d836d88617d38d9862d1)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In spite of a comment suggesting otherwise, os._exit() does not flush
buffered output from file descriptors before exiting the process like
os.exit() does. This means that any un-flushed output is lost in the
daemon process, in particular the traceback from any thrown exceptions,
making debugging exceptions in the daemon quite difficult.
The solution is to flush stdout and stderr before exiting.
(Bitbake rev: fcc8e1ff53696f78dd64b4ee32f3c433b7a47df0)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If there are events in the UI queue we want to print them regardless of
whether we're handling an exception or something like SystemExit.
This improves error messages for some other failure cases where currently
no logging would get printed and leave the user confused as to what went
wrong.
(Bitbake rev: 76c4f2c20216719736766e8ae7d089ccd061b71b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was originally based on some other code but its mostly misleading
comments now. Massively clean this up and accept its now a total fork.
There are no funciton changes here, just cleanup.
(Bitbake rev: 3daa9001269e5b9156d0eb3299d2628d2d219fff)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When we create the child, if an exception occurred it was transfering
back into the parent context. We don't want to do that us use a try/finally
to ensure we exit.
We need to ensure a traceback is printed and any queued UI messages which
may not have made it to the client UI at this point.
(Bitbake rev: dec1d2c26f6cb3ffeb44beaab0129cd531a6d08b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently if this code is used with something like oeqa's xml logging
it fails as sys.stdout is an io stream. Add in try/except to handle
this case.
Add a waitpid() call to remove a zombie whilst forking.
Also, append to the logfile, don't overwrite it (otherwise
debugging can be a real pain when the server is restarting for
unknown reasons).
(Bitbake rev: 4e780fa19fc720948cf73133f56f7d837ad9283a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(Bitbake rev: 587b144ee409d444494d8d7f2d1c53ede8f7c953)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(Bitbake rev: fd293c5fcc89bc7a541d09e88a6aec5e0b2a1db2)
Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
