Server is on a sub domain, with ssl.
I’m running a xibo 4.1.0 installation.
The server runs normal for a few hours.
At random i get then: SQLSTATE[HY000] [2002] php_network_getaddresses: getaddrinfo for cms-db failed: Temporary failure in name resolution
Xibo is then gone.
When i reboot, everything runs then normal… till the sqlstate error appears.
I have added only the networks lines tot cms-db (mysql container) in cms_cutom-ports.yml.
Without the conmtainer runs very unstable …
I used the github 4.1.0 version.
2024-11-11T12:24:58.603282Z 0 [Warning] [MY-011068] [Server] The syntax '--skip-host-cache' is deprecated and will be removed in a future release. Please use SET GLOBAL host_cache_size=0 instead.
2024-11-11T12:24:58.608286Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.39) starting as process 1
2024-11-11T12:24:58.632066Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2024-11-11T12:24:59.359324Z 1 [System] [MY-013577] [InnoDB] InnoDB initialization has ended.
2024-11-11T12:25:00.355569Z 0 [System] [MY-010229] [Server] Starting XA crash recovery...
2024-11-11T12:25:00.376071Z 0 [System] [MY-010232] [Server] XA crash recovery finished.
2024-11-11T12:25:00.839667Z 0 [Warning] [MY-010068] [Server] CA certificate ca.pem is self signed.
2024-11-11T12:25:00.839883Z 0 [System] [MY-013602] [Server] Channel mysql_main configured to support TLS. Encrypted connections are now supported for this channel.
2024-11-11T12:25:00.854974Z 0 [Warning] [MY-011810] [Server] Insecure configuration for --pid-file: Location '/var/run/mysqld' in the path is accessible to all OS users. Consider choosing a different directory.
2024-11-11T12:25:01.041721Z 0 [System] [MY-010931] [Server] /usr/sbin/mysqld: ready for connections. Version: '8.0.39' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server - GPL.
2024-11-11T12:25:01.041806Z 0 [System] [MY-011323] [Server] X Plugin ready for connections. Bind-address: '::' port: 33060, socket: /var/run/mysqld/mysqlx.sock
No. That option is set by the mysql container itself, not us, so it’s unrelated. There’s no errors or anything that shows me a problem in that log - other than it did crash recovery which suggests that the container was killed rather than stopped previously.