linux/poky.git/bitbake/lib/bb/server, branch thud

bitbake: server/process: Add missing exception raise

2019-02-06T08:32:00+00:00

The intent of the code was to catch one kind of error, it was actually swallowing all exceptions and looping indefinitely. Fix it to work as intended. This explains some mystery hangs we've been seeing. (Bitbake rev: d89358c7b8aa69f12b8c384c4fdb493782633494) Signed-off-by: Richard Purdie

bitbake: process: Rewrite multiple connection handling

2019-01-28T17:03:14+00:00

If the bitbake server recieved multiple connections, it currently closes ones it can't handle (while its dealing with another). This is rather antisocial behaviour which causes clients to quickly run through their retries and abort. Instead, queue any other connections until the current one is closed. This way the client can decide when it wants to stop waiting for the server. If the client is gone by the time we handle it, we handle that gracefully. This also fixes a number of bugs in the connection handling where connections which did drop early were badly handled causing tracebacks in the logs. Also, handle queue incomming connections in a loop to ensure that the main client handling doesn't starve that piece of the system. This code was stress tested by running 50 connection attempts in parallel at once, ensuring the code correctly handled them. (Bitbake rev: 220193dc38c4e78cb7cf36132a3a5b499a35bc8a) Signed-off-by: Richard Purdie

bitbake: process: Handle EWOULDBLOCK in socket connect

2019-01-28T17:03:14+00:00

Now that we set a timeout for the socket, it can return EWOULDBLOCK if a signal or other event happens to wake up even if we don't timeout. If this happens, retry the connection, else we simply see it quickly loop through the retries and abort the connection in a very short interval. (Bitbake rev: c2000651a200530ba08161207ade5eea8bbeec43) Signed-off-by: Richard Purdie

bitbake: process.py: Set socket timeout to 10 seconds

2019-01-28T17:03:14+00:00

The current value of 2 seconds has shown to be short in wider testing. (Bitbake rev: 469cc520593ba52775a373faad03072b7af05dba) Signed-off-by: Richard Purdie

bitbake: server/process: Ensure socket has a timeout set

2019-01-28T17:03:14+00:00

We're seeing hangs in oe-selftest where server startup and shutdown are racing. The assumption was a connect would timeout however no timeout is set which can leave processes hanging. Set a short timeout for the connection to avoid this. (Bitbake rev: 833d95f538c007c27c6eb8d8f2f97094dc2b1a41) Signed-off-by: Richard Purdie

bitbake: lib/bb/server: Avoid UnboundLocalError traceback

2019-01-28T17:03:13+00:00

Traceback (most recent call last): File "/home/pokybuild/yocto-worker/nightly-oe-selftest/build/bitbake/lib/bb/main.py", line 464, in setup_bitbake server_connection = bb.server.process.connectProcessServer(sockname, featureset) File "/home/pokybuild/yocto-worker/nightly-oe-selftest/build/bitbake/lib/bb/server/process.py", line 490, in connectProcessServer if command_chan_recv: UnboundLocalError: local variable 'command_chan_recv' referenced before assignment (Bitbake rev: 257ed88590883f46beec0164749e45733e67954e) Signed-off-by: Richard Purdie

bitbake: server/process: Handle short reads

2019-01-28T17:03:13+00:00

Its possible the read may return a smaller number of characters. Remove the possibility by using a single character to signal the server is ready. (Bitbake rev: 7fb2d6bed06439e59a81dd91798d886ee0a72e99) Signed-off-by: Richard Purdie

bitbake: server/process: Increase server startup time delay

2019-01-28T17:03:13+00:00

On loaded production systems we've seen bitbake server take over 40s to start up. Increase the timeout to 90s which tries to avoid failures in selftests. The delays come from setting up the inotify watches (31s) so can't really be avoided. After 5s delay we now warn the user we're waiting for 90s so the interactive exeperience shouldn't be much changed and its very unlikely the user would see that anyway. (Bitbake rev: 492a5c1b32bee1f5d7978954ee0ebdf4fccdf56f) Signed-off-by: Richard Purdie

bitbake: server/process: Show last 60 lines of the log if the server didn't start

2019-01-08T20:18:55+00:00

We're seeing issues where the server doesn't start with no logs as to why. Allow the server to print the last 60 log lines just in case this shows us something useful about what is failing. (Bitbake rev: 1351978585b76262cb104f3d609d79c184ee5d2b) Signed-off-by: Richard Purdie

bitbake: server/process: Show the last 60 log lines, not the last 10

2019-01-08T20:18:55+00:00

10 log lines may not capture any full traceback, increase the number of lines to 60 which covers most tracebacks. (Bitbake rev: 2626ff964c0a5726037e539cfd07027aded0b7a9) Signed-off-by: Richard Purdie