Comments (6)
Since this behavior is intentional, it is not a bug but a feature request.
However, you are right that it has a specific negative impact on ioBroker Slaves. Therefore, I will check if we can safely modify this behavior, at least for Slave Containers.
It might also be possible to link the "keep-alive function" of the container to the maintenance mode.
Thank you very much for your suggestion for improvement.
Regards,
André
from iobroker.docker.
The issue is not limited to satellite instances, since any instance, that somehow crashes, has this fate.
So I propose, as you suggested, to rewire/fix the keep-alive functionality such that it works for all instances and not only for satellite ones.
from iobroker.docker.
It is not as easy as it sounds.
As using the maintenance script is not mandatory yet, people still using the "hacky way" described in the docs (https://docs.buanet.de/iobroker-docker-image/docs/#iobroker-js-controller-core-updates) to update js-controller.
So making the keep-alive dependent on the maintenance mode this will break the familiar way a lot of users use.
Not sure if we should do this.
from iobroker.docker.
Calling it yourself "the hacky way" sounds like an ideal candidate for deprecation, especially since this is in this very containers documentation, that can easily be modified ;)
Anyhow, I propose two ideas:
Method1: One way would be making users aware about the maintenance mode via a shutdown message:
pkill -u iobroker # user is about to use the old 'hacky' way
# entrypoint.sh then shows the message below...
ioBroker has stopped working. If you intended to perform maintenance such as upgrading the js-controller, use "maintenance on" before and "maintenance off" after your intended action
This can be of course written in a better way - including links to the docs. This would nudge people towards using maintenance mode.
Method2: If you on the other hand would like to keep things the way they are (for now), I propose an ENV variable (e.g. IOB_MAINTENANCE_MODE_MANDATORY):
- When not set or false, the container behaves as it is right now
- When set, the keep-alive function is only present, when in maintenance mode. If maintenance mode is not toggled and ioBroker stops working (e.g. due to a crash), the container simply stops (so docker can restart it, if set so).
I think, the second approach would satisfy both of us, even though it wouldn't fix the underlying issue.
from iobroker.docker.
Calling it yourself "the hacky way" sounds like an ideal candidate for deprecation, especially since this is in this very containers documentation, that can easily be modified ;)
deprecation sounds good, but your are not the one answering the questions and issues of people not reading the docs or changelogs...
making users aware about the maintenance mode via a shutdown message
pkill -u iobroker
kills all processes running as user iobroker, so it might be quite a challenge to display a message in that situation...
I propose an ENV variable
No. I would not support the idea of another env for this. In the end the container has to stay administrable and supportable. Every new env makes it more complicated.
It would be just a repetition of a short story when I added an env to deactivate the permission check at startup (because "it takes so long 😮") and getting issues a year later about permissions errors when running/ updating the container...
Your idea is stated here as enhancement. We will see.
Regards,
André
from iobroker.docker.
Calling it yourself "the hacky way" sounds like an ideal candidate for deprecation, especially since this is in this very containers documentation, that can easily be modified ;)
deprecation sounds good, but your are not the one answering the questions and issues of people not reading the docs or changelogs...
making users aware about the maintenance mode via a shutdown message
pkill -u iobroker
kills all processes running as user iobroker, so it might be quite a challenge to display a message in that situation...
If you echo a message to /dev/pts/0, it would appear on a users screen, if he entered the container in interactive and terminal mode (docker exec -it /bin/bash). One can even loop over multiple /dev/pts/* devices to send the message to all ttys, that have been spawned when entering the container.
See my workaround Dockerfile below
I propose an ENV variable
No. I would not support the idea of another env for this. In the end the container has to stay administrable and supportable. Every new env makes it more complicated. It would be just a repetition of a short story when I added an env to deactivate the permission check at startup (because "it takes so long 😮") and getting issues a year later about permissions errors when running/ updating the container...
I can understand that you want to keep complexity and workarounds as low a possible, which is a good thing IMHO.
Another method would be running iobroker via s6 and ensuring, that it keep running on a crash. But I yet have to come around with an idea on how to identify, if a user purposely "crashed" it via pkill
. Maybe by checking for the reason of the crash:
If it crashed due to missing db connections, just restart iobroker (accessible via the logs). But this all sounds a bit hacky too.
For the mean time, I wrote my own Docker container to mitigate crashes, since for an unknown reason, my satellite keeps on crashing randomly for the same reason all the time (sometimes it runs for weeks, sometimes just a few days or only hours).
FROM buanet/iobroker:latest
# WORKAROUND to disable maintenance mode keep-alive (+ reminder for myself, that I disabled it)
RUN sed -i '/^gosu iobroker tail/d' /opt/scripts/iobroker_startup.sh && echo 'if [ -c "/dev/pts/0" ]; then echo "ioBroker has stopped working. If you intended to perform maintenance such as upgrading the js-controller, use \"maintenance on\" before and \"maintenance off\" after your intended action" > /dev/pts/0; fi' >> /opt/scripts/iobroker_startup.sh
This basically modifyes the iobroker_startup.sh script such that instead of gosu iobroker tail -f /dev/null
it reads
echo "ioBroker has stopped working. If you intended to perform maintenance such as upgrading the js-controller, use \"maintenance on\" before and \"maintenance off\" after your intended action" > /dev/pts/0; fi'
from iobroker.docker.
Related Issues (20)
- [Problem]: Container working but unhealthy HOT 1
- [Feature Request]: possibility to call a restart from inside ioBroker (e.g. javascript-adapter) HOT 6
- [Feature Request]: Podman support (rootless by default) in installation script. HOT 6
- [Feature Request]: Working together on a helm chart HOT 2
- [Problem]: cannot pull most of the tags for ghcr.io/buanet/iobroker HOT 1
- [Feature Request]: Add set -e to healthcheck.sh HOT 1
- [Feature Request]: migrate to PUID/PGID since it is the defacto standard HOT 2
- [Problem]: userscripts are not owned by the SETGID/SETUID user HOT 2
- [Problem]: iobroker_startup.sh should respect traps HOT 3
- [Feature Request]: Make the list of available backups sorted
- [Problem]: arm/v7 support HOT 10
- [Problem]: Small typo in docs HOT 1
- [Problem]: Container on QNAP NAS: Backitup can't access mount point HOT 2
- [Problem]: Running Iobroker as a podman rootless container HOT 1
- [Problem]: iobroker gets killed by oom-kill constantly HOT 5
- Backup of influxdb running in different docker is not working HOT 8
- [Problem]: Update js-controller HOT 2
- Failed to load definitions for node: Error:
- The selected advertiser, \"avahi\", isn't available on this platform
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from iobroker.docker.