I’m using MicroOS with cockpit and a bunch of podman containers. The containers are set up to start automatically when the server boots up. Everything has worked fine for months.
All of a sudden a few days ago the containers don’t start after the 4am automatic update, or any reboot I issue. I also haven’t been able to load up cockpit on my phone… I can only get to cockpit on a computer.
But oddly all I need to do to get the containers running is load up the cockpit login screen… ie, navigate to 192.168.0.30:9090. I don’t need to login and I don’t need manually start the containers.
Has anyone experienced the same since a recent update or know how I might be able to fix this?
Wild guess: maybe some dependency is not available (ready) when the machine restarts after its nightly update, hence preventing cockpit from starting. The service file for it may have a too low default restart wait time, thus prompting it to restart very quickly which would eventually lead to a failed state after 5 unsuccessful restarts (in default config).
When you manually visit the website, it may try to start the service again and it succeeds since all dependencies are ready.
Looking at the cockpit journals should show the culprit.
Thanks guys… I had a look through the journals. Cockpit starts up OK but then throws out… but it’s looks like it’s been doing this for a long time and before I had container problems.
Mar 12 18:04:10 openSUSEMicroOs systemd[1]: Starting Cockpit Web Service...
Mar 12 18:04:10 openSUSEMicroOs systemd[1]: Started Cockpit Web Service.
Mar 12 18:04:11 openSUSEMicroOs cockpit-tls[10930]: cockpit-tls: gnutls_handshake failed: A TLS fatal alert has been received.