No description
803433fb62
Change the API endpoint to prevent retrieving monitor-output from a running instance. Instead, we require the caller to exit the API context before querying the monitor-output. This guarantees that the api-thread was synchronously taken down and scheduled any outstanding events. This fixes an issue where a side-channel notifies us of a buildroot exit, but the api-thread has not yet returned from epoll, and thus might not have dispatched pending I/O events, yet. If we instead wait for the thread to exit, we have a synchronous shutdown and know that all *ordered* kernel events must have been handled. In particular, imagine a build-root program running (like `echo` in the test_monitor unittest) which writes data to the stdout-pipe and then immediately exits. The syscall-order guarantees that the data is written to the pipe before the SIGCHLD is sent (or wait(2) returns). However, we retrieve the SIGCHLD from our main-thread usually (p.join() in our test, and BuildRoot() in our main code), while the pipe-reading is done from an API thread. Therefore, we might end up handling the SIGCHLD first (just imagine a single-threaded CPU that schedules the main task before the thread). To avoid this race, we can simply synchronize with the api-thread. Since we already have this synchronization as part of the api-thread takedown, it is as simple as stopping the api-thread before continuing with operations. Lastly, if a write operation to a pipe was issued, we are guaranteed that a SIGCHLD synchronization across processes is ordered correctly. Furthermore, the python event-loop also guarantees that stopping an event-loop will necessarily dispatch all outstanding events. A read is guaranteed to be outstanding in our race-scenario, so the read will be dispatched. The only possible problem is `_output_ready()` only dispatching a maximum of 4096 bytes. This might need to be fixed separately. A comment is left in place. |
||
|---|---|---|
| .github/workflows | ||
| assemblers | ||
| docs | ||
| osbuild | ||
| runners | ||
| samples | ||
| schemas | ||
| schutzbot | ||
| selinux | ||
| sources | ||
| stages | ||
| test | ||
| tools | ||
| .editorconfig | ||
| .gitignore | ||
| .pylintrc | ||
| .travis.yml | ||
| LICENSE | ||
| Makefile | ||
| NEWS.md | ||
| osbuild.spec | ||
| README.md | ||
| requirements.txt | ||
| setup.py | ||
OSBuild
Build-Pipelines for Operating System Artifacts
OSBuild is a pipeline-based build system for operating system artifacts. It defines a universal pipeline description and a build system to execute them, producing artifacts like operating system images, working towards an image build pipeline that is more comprehensible, reproducible, and extendable.
See the osbuild(1) man-page for details on how to run osbuild, the definition
of the pipeline description, and more.
Project
- Website: https://www.osbuild.org
- Bug Tracker: https://github.com/osbuild/osbuild/issues
Requirements
The requirements for this project are:
bubblewrap >= 0.4.0python >= 3.7
Additionally, the built-in stages require:
bash >= 5.0coreutils >= 8.31curl >= 7.68qemu-img >= 4.2.0rpm >= 4.15tar >= 1.32util-linux >= 235
At build-time, the following software is required:
python-docutils >= 0.13pkg-config >= 0.29
Build
The standard python package system is used. Consult upstream documentation for detailed help. In most situations the following commands are sufficient to build and install from source:
python setup.py build
python setup.py install --skip-build --root=/
The man-pages require python-docutils and can be built via:
rst2man docs/<input-file>.rst <output-file>
Repository:
- web: https://github.com/osbuild/osbuild
- https:
https://github.com/osbuild/osbuild.git - ssh:
git@github.com:osbuild/osbuild.git
License:
- Apache-2.0
- See LICENSE file for details.