ioBroker.docker icon indicating copy to clipboard operation
ioBroker.docker copied to clipboard

[Problem]: iobroker_startup.sh should respect traps

Open EugenMayer opened this issue 2 years ago • 2 comments

Description / Beschreibung

currently, when the iobroker process does not start due to issues (chown or others) the process is still running. While this is not an issue in itself and might be nice for debugging, the process does not longer respect kill signals since it has no trap.

This means if anything tells the container to shut down, it will not - the container will the be force fully killed after the "shutdown timeout / kill timeout" - this can be 60-120s of doing nothing.

We need to have a proper trap so the process ends right away (it does not need to wait for anything)

Image version

9.0.1

Docker logs / Docker Protokoll

-

EugenMayer avatar Jan 05 '24 00:01 EugenMayer

I just understood that this issue only arises when one runs with DEBUG: true https://github.com/buanet/ioBroker.docker/blob/main/debian12/scripts/iobroker_startup.sh#L43 - otherwise the container exists directly.

I guess this gives this a way lower prio for sure, since nobody should run ioBroker with DEBUG in production, right? We could still add the trap though, but i would understand that this is only for the possible corner case.

EugenMayer avatar Jan 05 '24 01:01 EugenMayer

this can be 60-120s of doing nothing.

Not sure if I get this right. As i know, the default shutdown time (SIGTERM) for Docker is 10s. If the container hasn't exited after that, Docker will kill it. True: After js-controller (the containers main process) is shut down, there is no more trap. This is intentional and I see no use case for that.

nobody should run ioBroker with DEBUG in production, right?

True: DEBUG is for generating debugging output and it slows down container startup. It should be disabled when not needed.

Maybe this will be solved too when we do #422.

By the way, when the iobroker process is not starting, I think you have other problems than a shutdown timeout and it is unreal to expect a graceful shutdown of the container. 😄

Regards, André

buanet avatar Jan 06 '24 23:01 buanet

I'll close this issue, as it is not planned at the moment.

buanet avatar Apr 05 '24 22:04 buanet