Ebusd container crash after start

[mefisto22]

Description

Container crash after start. I readed github issueses tried all off solutions, but non working. IPv6 disabled on host's sysctl.conf file. This will not the same issue like #751

Actual behavior

container crash

Expected behavior

download config and start pushing mqtt messages to mqtt broker

ebusd version

current source from git

ebusd arguments

-e 'EBUSD_LOG=all:debug'

Operating system

Debian 12 (Bookworm) / Ubuntu 22-23 / Raspberry Pi OS 12 (including lite)

CPU architecture

x64

Dockerized

latest

Hardware interface

adapter 3.0 WiFi

Related integration

MQTT generic

Logs

sudo docker run --name=ebusd -v /etc/localtime:/etc/localtime:ro -p 8888 -e 'EBUSD_LOG=all:debug' john30/ebusd --scanconfig -d ens:192.168.11.2:9999 --mqttport=1883 --mqtthost=192.168.11.32
2023-09-24 19:30:01.435 [network debug] SSL state 0=before SSL initialization: type 0x10=start, val 1=?
2023-09-24 19:30:01.435 [network debug] SSL state 0=before SSL initialization: type 0x1001=loop,connect, val 1=?
2023-09-24 19:30:01.435 [network debug] SSL BIO state 2 res -1
2023-09-24 19:30:09.489 [network debug] SSL BIO state 3 res 1
2023-09-24 19:30:09.489 [network debug] SSL BIO state 4 res 3
2023-09-24 19:30:09.489 [network debug] SSL BIO state 6 res 0
2023-09-24 19:30:09.489 [network debug] SSL state 12=SSLv3/TLS write client hello: type 0x1002=exit,connect, val -1=?
2023-09-24 19:30:09.489 [network error] HTTP connect: timed out after 2 sec
2023-09-24 19:30:09.489 [network error] HTTP new_ssl_conn: 336462231=shutdown while in init
2023-09-24 19:30:09.489 [main error] invalid configPath URL (connect)

curl -vvv https://cfg.ebusd.eu

• Trying 202.61.232.73:443...
• Connected to cfg.ebusd.eu (202.61.232.73) port 443 (#0)
• ALPN: offers h2,http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (IN), TLS handshake, CERT verify (15):
• TLSv1.3 (IN), TLS handshake, Finished (20):
• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (OUT), TLS handshake, Finished (20):
• SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
• ALPN: server accepted h2
• Server certificate:
• subject: CN=cfg.ebusd.eu
• start date: Aug 2 14:56:38 2023 GMT
• expire date: Oct 31 14:56:37 2023 GMT
• subjectAltName: host "cfg.ebusd.eu" matched cert's "cfg.ebusd.eu"
• issuer: C=US; O=Let's Encrypt; CN=R3
• SSL certificate verify ok.
• using HTTP/2
• h2h3 [:method: GET]
• h2h3 [:path: /]
• h2h3 [:scheme: https]
• h2h3 [:authority: cfg.ebusd.eu]
• h2h3 [user-agent: curl/7.88.1]
• h2h3 [accept: /]
• Using Stream ID: 1 (easy handle 0x5555ffbcfc70)

GET / HTTP/2
Host: cfg.ebusd.eu
user-agent: curl/7.88.1
accept: /

• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• old SSL session ID is stale, removing
  < HTTP/2 301
  < server: nginx
  < date: Sun, 24 Sep 2023 18:49:49 GMT
  < content-type: text/html; charset=UTF-8
  < content-length: 0
  < location: https://upd.ebusd.eu/
  <
• Connection #0 to host cfg.ebusd.eu left intact

openssl s_client -connect cfg.ebusd.eu:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = cfg.ebusd.eu
verify return:1

[john30]

maybe just a timeout. check how long curl takes to get a response

[mefisto22]

~$ curltime cfg.ebusd.eu
time_namelookup: 0.002232s
time_connect: 0.024950s
time_appconnect: 0.000000s
time_pretransfer: 0.025007s
time_redirect: 0.000000s
time_starttransfer: 0.049609s
----------
time_total: 0.049673s

[john30]

then try on your container host with including the files in the image instead. if it then works, it is surely a matter of the volume/driver/bind

[c-huetter]

Moved to a separate issue.

[john30]

@c-huetter clearly this is a completely different topic, so don't misuse an existing issue for such. anyway: you missed the environment settings of the container that influence this

[c-huetter]

Makes sense, I'll open a new issue including the environment setting.

[mefisto22]

then try on your container host with including the files in the image instead. if it then works, it is surely a matter of the volume/driver/bind

when i download the files manually, container works