starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Kuma stops working after ~5 minutes #3161

New issue

Closed

opened 2026-02-28 03:20:10 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-28 03:20:10 -05:00

Owner

Originally created by @PapeThePope on GitHub (Feb 28, 2024).

⚠️ Please verify that this question has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

📝 Describe your problem

Hi im using uptime-kuma in a docker container on a redhat system.
Unfortunately after working for around 5 Minutes uptime-kuma just stops working. The container seems to be loosing any network connectivity.
It cant Ping a local server and it cant be accessed via Browser.

📝 Error Message(s) or Log

On Container Restart i get the following error (only if i restart after its broken):

Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg.
ERRO[0004] Unable to clean up network for container XXX: "tearing down network namespace configuration for container XXX: 1 error occurred:
    * plugin type=\"bridge\" failed (delete): cni plugin bridge failed: running [/sbin/iptables -t nat -D POSTROUTING -s XX.XX.XX.XX -j CNI-ABC -m comment --comment name: \"podman\" id: \"XXX\" --wait]: exit status 2: iptables v1.8.5 (nf_tables): Chain 'CNI-ABC' does not exist
Try `iptables -h' or 'iptables --help' for more information."

🐻 Uptime-Kuma Version

1.23.3

💻 Operating System and Arch

Red Hat Enterprise Linux release 8.9

🌐 Browser

Chrome Version 122

🖥️ Deployment Environment

Runtime: podman version 4.6.1
Database: SQLLITE (Container Standard Settings)
Filesystem used to store the database on: container internal?
number of monitors: 1

Originally created by @PapeThePope on GitHub (Feb 28, 2024). ### ⚠️ Please verify that this question has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### 📝 Describe your problem Hi im using uptime-kuma in a docker container on a redhat system. Unfortunately after working for around 5 Minutes uptime-kuma just stops working. The container seems to be loosing any network connectivity. It cant Ping a local server and it cant be accessed via Browser. ### 📝 Error Message(s) or Log On Container Restart i get the following error (only if i restart after its broken): ``` Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg. ERRO[0004] Unable to clean up network for container XXX: "tearing down network namespace configuration for container XXX: 1 error occurred: * plugin type=\"bridge\" failed (delete): cni plugin bridge failed: running [/sbin/iptables -t nat -D POSTROUTING -s XX.XX.XX.XX -j CNI-ABC -m comment --comment name: \"podman\" id: \"XXX\" --wait]: exit status 2: iptables v1.8.5 (nf_tables): Chain 'CNI-ABC' does not exist Try `iptables -h' or 'iptables --help' for more information." ``` ### 🐻 Uptime-Kuma Version 1.23.3 ### 💻 Operating System and Arch Red Hat Enterprise Linux release 8.9 ### 🌐 Browser Chrome Version 122 ### 🖥️ Deployment Environment - Runtime: podman version 4.6.1 - Database: SQLLITE (Container Standard Settings) - Filesystem used to store the database on: container internal? - number of monitors: 1

deekerman

2026-02-28 03:20:10 -05:00

closed this issue
added the
question

A:core

help
labels

deekerman commented

2026-02-28 03:20:17 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 28, 2024):

I think your podman installation has some defects. Have you looked here:

https://github.com/containers/podman/issues/5335
Given that you specified RHEL, maybe you can (I can't) access https://access.redhat.com/solutions/4859291

@CommanderStorm commented on GitHub (Feb 28, 2024): I think your podman installation has some defects. Have you looked here: - https://github.com/containers/podman/issues/5335 - Given that you specified RHEL, maybe you can (I can't) access https://access.redhat.com/solutions/4859291

deekerman commented

2026-02-28 03:20:17 -05:00

Author

Owner

@PapeThePope commented on GitHub (Feb 28, 2024):

I have another application on the same host in a container and this one is working fine :(
For example it also connects the same local server.

It seems so weird that it just stops after ~5 Minutes and before everything is fine?

I looked at the first link, but cant find a good comparison to my problem, especially with the other app working in mind. And unfortunately i dont have access the redhat forums

@PapeThePope commented on GitHub (Feb 28, 2024): I have another application on the same host in a container and this one is working fine :( For example it also connects the same local server. It seems so weird that it just stops after ~5 Minutes and before everything is fine? I looked at the first link, but cant find a good comparison to my problem, especially with the other app working in mind. And unfortunately i dont have access the redhat forums

deekerman commented

2026-02-28 03:20:17 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 28, 2024):

have you looked into the podman logs what happes at the 5m mark?

@CommanderStorm commented on GitHub (Feb 28, 2024): have you looked into the podman logs what happes at the 5m mark?

deekerman commented

2026-02-28 03:20:17 -05:00

Author

Owner

@PapeThePope commented on GitHub (Feb 29, 2024):

The only thing i see in the logs of the pod is:
2024-02-29T08:30:51+01:00 [MONITOR] WARN: Monitor #1 'XXX': Pending: PING XXX (XXX) 56(84) bytes of data.
--- XXX ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 242ms

Which goes in line, that the pod just looses connection, as the server is reachable from the host and other container.
Time varies though. Was like 10 Minutes now.

I also tried to add a new Network to podman, to have both containers run on seperate networks, which unfortunately didnt work either :(

@PapeThePope commented on GitHub (Feb 29, 2024): The only thing i see in the logs of the pod is: 2024-02-29T08:30:51+01:00 [MONITOR] WARN: Monitor #1 'XXX': Pending: PING XXX (XXX) 56(84) bytes of data. --- XXX ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 242ms Which goes in line, that the pod just looses connection, as the server is reachable from the host and other container. Time varies though. Was like 10 Minutes now. I also tried to add a new Network to podman, to have both containers run on seperate networks, which unfortunately didnt work either :(

deekerman commented

2026-02-28 03:20:17 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Feb 29, 2024):

I am NOT talking about the pod logs, I am talking about the podman logs (i.e. the logs of your runtime, not the pod being run)

@CommanderStorm commented on GitHub (Feb 29, 2024): I am NOT talking about the pod logs, I am talking about the podman logs (i.e. the logs of your runtime, not the pod being run)

deekerman commented

2026-02-28 03:20:17 -05:00

Author

Owner

@louislam commented on GitHub (Mar 1, 2024):

exit status 2: iptables v1.8.5 (nf_tables): Chain 'CNI-ABC' does not exist

Normally Podman will add some rules to the iptables (firewall) silently. I guess you have other programs which removed/overrided Podman's rules. For my experience, VestaCP's Firewall GUI did that.

@louislam commented on GitHub (Mar 1, 2024): > exit status 2: iptables v1.8.5 (nf_tables): Chain 'CNI-ABC' does not exist Normally Podman will add some rules to the iptables (firewall) silently. I guess you have other programs which removed/overrided Podman's rules. For my experience, VestaCP's Firewall GUI did that.

deekerman commented

2026-02-28 03:20:17 -05:00

Author

Owner

@PapeThePope commented on GitHub (Mar 6, 2024):

I am NOT talking about the pod logs, I am talking about the podman logs (i.e. the logs of your runtime, not the pod being run)

Actually Podman did not log anything for that, funny stuff :(

I did change the network mode to host, which solved the issue in my case, as it is ok for me to run it like that.

@PapeThePope commented on GitHub (Mar 6, 2024): > I am NOT talking about the pod logs, I am talking about the podman logs (i.e. the logs of your runtime, not the pod being run) Actually Podman did not log anything for that, funny stuff :( I did **change the network mode to host**, which solved the issue in my case, as it is ok for me to run it like that.

deekerman commented

2026-02-28 03:20:17 -05:00

Author

Owner

@TechJedi51 commented on GitHub (Feb 27, 2025):

I am seeing the same thing in Portainer. This just started to happen after the last update. I am seeing this in the logs:


[dumb-init] extra/entrypoint.sh: No such file or directory

[2025-01-30 17:54:56] Error: Unable to acquire a connection
    at Client_SQLite3.acquireConnection (/app/node_modules/knex/lib/client.js:303:13)
    at Runner.ensureConnection (/app/node_modules/knex/lib/execution/runner.js:287:46)
    at Runner.run (/app/node_modules/knex/lib/execution/runner.js:30:30)
    at Target.then (/app/node_modules/knex/lib/builder-interface-augmenter.js:24:43)
[2025-01-30 17:54:57] Error: Unable to acquire a connection
    at Client_SQLite3.acquireConnection (/app/node_modules/knex/lib/client.js:303:13)
    at Runner.ensureConnection (/app/node_modules/knex/lib/execution/runner.js:287:46)
    at Runner.run (/app/node_modules/knex/lib/execution/runner.js:30:30)
    at Target.then (/app/node_modules/knex/lib/builder-interface-augmenter.js:24:43)

@TechJedi51 commented on GitHub (Feb 27, 2025): I am seeing the same thing in Portainer. This just started to happen after the last update. I am seeing this in the logs: ```[dumb-init] extra/entrypoint.sh: No such file or directory [dumb-init] extra/entrypoint.sh: No such file or directory [2025-01-30 17:54:56] Error: Unable to acquire a connection at Client_SQLite3.acquireConnection (/app/node_modules/knex/lib/client.js:303:13) at Runner.ensureConnection (/app/node_modules/knex/lib/execution/runner.js:287:46) at Runner.run (/app/node_modules/knex/lib/execution/runner.js:30:30) at Target.then (/app/node_modules/knex/lib/builder-interface-augmenter.js:24:43) [2025-01-30 17:54:57] Error: Unable to acquire a connection at Client_SQLite3.acquireConnection (/app/node_modules/knex/lib/client.js:303:13) at Runner.ensureConnection (/app/node_modules/knex/lib/execution/runner.js:287:46) at Runner.run (/app/node_modules/knex/lib/execution/runner.js:30:30) at Target.then (/app/node_modules/knex/lib/builder-interface-augmenter.js:24:43) ```