Container reconfiguration is broken #930
Comments
wkz
added
bug
|
|
@troglobit Milestone 25.02? I will assume this was the intention during last CCB, and add it to 25.02 now. |
Indeed, thanks for keeping track 🙏 |
troglobit
added a commit
that referenced
this issue
Feb 23, 2025
When updating a container configuration we need to rerun the setup stage of the container. However, a run/task in Finit only runs once for each runlevel, meaning changes at runtime of a container was broken. This is a refactor of the container script to allow it to also run as a pre:script in the Finit setup stage of a sysv/service. Also included is a fix to the timeout/retry handling in case the container setup fails. We must call `read -t 60` *before* calling `ip monitor`, otherwise it will not be called until `ip monitor` returns. This patch requires Finit v4.9, or later. Fixes #930 Signed-off-by: Joachim Wiberg <[email protected]>
troglobit
added a commit
that referenced
this issue
Feb 23, 2025
Add new test step that adds a content mount to /var/www/index.html to verify that changes to a running container are activated. This test pass was previously part of the container bridge test, but was moved here to allow that test to focus on bridge specific checks. Issue #930 Signed-off-by: Joachim Wiberg <[email protected]>
troglobit
added a commit
that referenced
this issue
Feb 23, 2025
When updating a container configuration we need to rerun the setup stage of the container. However, a run/task in Finit only runs once for each runlevel, meaning changes at runtime of a container was broken. This is a refactor of the container script to allow it to also run as a pre:script in the Finit setup stage of a sysv/service. Also included is a fix to the timeout/retry handling in case the container setup fails. We must call `read -t 60` *before* calling `ip monitor`, otherwise it will not be called until `ip monitor` returns. This patch requires Finit v4.9, or later. Fixes #930 Signed-off-by: Joachim Wiberg <[email protected]>
troglobit
added a commit
that referenced
this issue
Feb 23, 2025
Add new test step that adds a content mount to /var/www/index.html to verify that changes to a running container are activated. This test pass was previously part of the container bridge test, but was moved here to allow that test to focus on bridge specific checks. Issue #930 Signed-off-by: Joachim Wiberg <[email protected]>
troglobit
added a commit
that referenced
this issue
Feb 23, 2025
When updating a container configuration we need to rerun the setup stage of the container. However, a run/task in Finit only runs once for each runlevel, meaning changes at runtime of a container was broken. This is a refactor of the container script to allow it to also run as a pre:script in the Finit setup stage of a sysv/service. Also included is a fix to the timeout/retry handling in case the container setup fails. We must call `read -t 60` *before* calling `ip monitor`, otherwise it will not be called until `ip monitor` returns. This patch requires Finit v4.9, or later. Fixes #930 Signed-off-by: Joachim Wiberg <[email protected]>
troglobit
added a commit
that referenced
this issue
Feb 23, 2025
Add new test step that adds a content mount to /var/www/index.html to verify that changes to a running container are activated. This test pass was previously part of the container bridge test, but was moved here to allow that test to focus on bridge specific checks. Issue #930 Signed-off-by: Joachim Wiberg <[email protected]>
troglobit
added a commit
that referenced
this issue
Feb 24, 2025
Add new test step that adds a content mount to /var/www/index.html to verify that changes to a running container are activated. This test pass was previously part of the container bridge test, but was moved here to allow that test to focus on bridge specific checks. Issue #930 Signed-off-by: Joachim Wiberg <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Current Behavior
After a container has been launched any further reconfiguration is not applied until after reboot or a manual
container {stop, setup, start}cycle.Expected Behavior
docker://nginx:alpineAs expected, the default landing page is accessible
The custom landing page is expected to be seen, but the default is still shown
Steps To Reproduce
No response
Additional information
The root cause is that the download/setup phase for the container is run by
finitas atask. So unless the runlevel changes (which it does not during a normal reconfig-cycle), the setup phase is not run again.The text was updated successfully, but these errors were encountered: