Mirror of git.yoctoproject.org/poky https://git.enea.com/cgit/linux/poky.git/atom?h=mickledore 2023-03-07T12:52:10+00:00 2023-03-07T12:52:10+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2023-03-07T12:49:08+00:00 urn:sha1:082e46f9ca784a3c714a18642904cccf133f408f After changes in bitbake b5215887d2f8ea3f28f1ebda721bd5b8f93ec7f3, "process/cooker/command: Fix currentAsyncCommand locking/races", command.py assumes it has access to the process server but the xmlrpc backend was passing in the xmlrpc server object leading to errors like: xmlrpc.client.Fault: <Fault 1: "<class 'AttributeError'>:'BitBakeXMLRPCServer' object has no attribute 'set_async_cmd'"> Fixing to pass the process server to command.py resolves this issue. [YOCTO #15008] (Bitbake rev: ce5b65d5fada474ef21ac28440af6ad45287650a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2023-02-20T15:18:53+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2023-02-20T09:30:44+00:00 urn:sha1:76db0baba26a5da5382f7cc44c64eb705e24e638 If the inotifier code has an exception, bitbake currently hangs. Catch any exception and exit if seen. Also check the idle thread is alive and exit if it disappears. This should stop bitbake hanging if such a situation arises in future such as this example: 3323260 21:48:31.554468 Running command ['getVariable', 'BBINCLUDELOGS'] Exception in thread Thread-1 (idle_thread): Traceback (most recent call last): File "/usr/lib64/python3.10/threading.py", line 1016, in _bootstrap_inner self.run() File "/usr/lib64/python3.10/threading.py", line 953, in run self._target(*self._args, **self._kwargs) File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/server/process.py", line 408, in idle_thread self.cooker.process_inotify_updates() File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/bb/cooker.py", line 256, in process_inotify_updates n.read_events() File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/bitbake/lib/pyinotify.py", line 1207, in read_events if fcntl.ioctl(self._fd, termios.FIONREAD, buf_, 1) == -1: OSError: [Errno 9] Bad file descriptor 3323260 21:48:32.206995 Command Completed (socket: True) (Bitbake rev: 358b5b02d5de1ab0f98104c4ec4953e46999b9a5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2023-01-24T21:59:44+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2023-01-18T14:06:45+00:00 urn:sha1:18d2c489f065f2eabe4024f2db3a1d6e0ca573c0 We need to check against the first line of the file, fix the typo. (Bitbake rev: 4abc598fb01d426394f4222dfc752e620a8e1b7b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2023-01-14T14:33:00+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2023-01-14T13:35:08+00:00 urn:sha1:11698e027d71967153b272bf34996bee8f3908e5 If memory resident bitbake is active and the build directory is renamed upon build completion, several bad things can happen: * the old build directory could be re-created to contain a lockfile leaving an empty directory behind * a lockfile for a new build could be found and attempt to be locked This patch avoids creating an empty directory (not perfectly, but should work in the majority of cases - an empty directory is cosmetic). It also now compares the lock file contents to it's own pid and just exits if it doesn't match, it is clearly then belonging to some new process. This will be combined with bitbake shutdown calls on the autobuilder to ensure "saved" build directories, or build directories being deleted by clobberdir don't do strange things. (Bitbake rev: b986eac18b6a8bf633f5ef15f32f68de4c86173b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2023-01-11T23:16:31+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2023-01-11T16:09:22+00:00 urn:sha1:e26e0b92e813bea0d5b875c936ff390937c860f0 Rather than risk the heartbeat event code locking up the server control socket, handle it in the 'idle' thread with the other work. The aim is to remove it as a possible issue with some ongoing hangs. (Bitbake rev: 0f9a0c7853b181817bf01863a26da21412376294) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2023-01-11T10:58:36+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2023-01-09T23:17:56+00:00 urn:sha1:165e8b563d400bf54c317659a267db85e8c34006 currentAsyncCommand currently doesn't have any locking and we have a conflict in "idle" conditions since the idle functions count needs to be zero *and* there needs to be no active command. Move the changes/checks of currentAsyncCommand to within the lock and then we can add it to the condition for idle, simplifying some of the code. (Bitbake rev: b5215887d2f8ea3f28f1ebda721bd5b8f93ec7f3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2023-01-06T17:40:01+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2023-01-04T17:56:58+00:00 urn:sha1:7f556c68619377224560066e92a88469919b335b We no longer need to abstract the inotify callback handler, remove the abstraction and simplify/clean up the code. (Bitbake rev: af4ccab8acc49e91bf7647f209d69f4858618466) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2023-01-05T11:50:17+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2023-01-04T12:32:35+00:00 urn:sha1:a19687acd12497d727203e63d74b2703387f34a6 The thread/process locks we use translate to futexes in Linux. If a process dies holding the lock, anything else trying to take the lock will hang indefinitely. An example would be the OOM killer taking out a parser process. To avoid bitbake processes just hanging indefinitely, add a timeout to our lock calls using a context manager. If we can't obtain the lock after waiting 5 minutes, hard exit out using os._exit(1). Use _exit() to avoid locking in any other places trying to write error messages to event handler queues (which also need locks). Whilst a bit harsh, this should mean we stop having lots of long running processes in cases where things are never going to work out and also avoids hanging builds on the autobuilder. (Bitbake rev: d2a3f662b0eed900fc012a392bfa0a365df0df9b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2022-12-31T17:05:17+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2022-12-30T22:13:45+00:00 urn:sha1:4c57c6eeecc43d0479380144f3073e61a8b43375 When bitbake is off running heavier "idle" commands, it doesn't service it's command socket which means stopping/interrupting it is hard. It also means we can't "ping" from the UI to know if it is still alive. For those reasons, split idle command execution into it's own thread. The commands are generally already self containted so this is easier than expected. We do have to be careful to only handle inotify poll() from a single thread at a time. It also means we always have to use a thread lock when sending events since both the idle thread and the command thread may generate log messages (and hence events). The patch depends on previous fixes to the builtins locking in event.py and the heartbeat enable/disable changes as well as other locking additions. We use a condition to signal from the idle thread when other sections of code can continue, thanks to Joshua Watt for the review and tweaks squashed into this patch. We do have some sync points where we need to ensure any currently executing commands have finished before we can start a new async command for example. (Bitbake rev: 67dd9a5e84811df8869a82da6a37a41ee8fe94e2) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> 2022-12-31T17:05:17+00:00 Richard Purdie richard.purdie@linuxfoundation.org 2022-12-30T21:55:59+00:00 urn:sha1:3cc9aed5a59d7b72b98ef40727102c98b031f911 In preparation for adding splitting bitbakes work into two threads, add locking around the idle functions list accesses. (Bitbake rev: a9c63ce8932898b595fb7776cf5467d3c0afe4f7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>