threefoldtech / tfgrid-sdk-ts

Apache License 2.0
4 stars 8 forks source link

🐞 [Bug]: Bad gateway for wordpress solution main net node 481 #2634

Closed Mik-TF closed 6 months ago

Mik-TF commented 6 months ago

Is there an existing issue for this?

which package/s did you face the problem with?

Dashboard

What happened?

Bad gateway when deploying wordpress solution on main net node 481. no ipv4.

It worked when deploying on test net node 1, no ipv4

Steps To Reproduce

  1. go to dashboard.grid.tf
  2. deploy wordpress solution with custom domain, gent01.grid.tf gateway, no ipv4, set DNS A record
  3. click on admin or wordpress button
  4. bad gateway

Note: I could SSH with wireguard on the node 481 but the wordpress site and admin site didn't work.

Note: I did a test with dashboard.test.grid.tf, node 1, no ipv4, custom domain, gent02.grid.tf and it worked. I had to go to admin panel, update the database and then access the wordpress website.

which network/s did you face the problem on?

Main

version

latest

Twin ID/s

No response

Node ID/s

481

Farm ID/s

vcc3 farm name

Contract ID/s

No response

Relevant screenshots/screen records

image

Relevant log output

{
  "version": 0,
  "contractId": 407373,
  "nodeId": 481,
  "name": "word0",
  "created": 1713977520,
  "status": "ok",
  "message": "",
  "flist": "https://hub.grid.tf/tf-official-apps/tf-wordpress-latest.flist",
  "publicIP": null,
  "planetary": "300:ef1c:abb7:eca0:4f18:784a:30bc:9f5d",
  "myceliumIP": "",
  "interfaces": [
    {
      "network": "nwwqr07",
      "ip": "10.20.4.2"
    }
  ],
  "capacity": {
    "cpu": 2,
    "memory": 4096
  },
  "mounts": [
    {
      "name": "diskm8e",
      "mountPoint": "/var/www/html",
      "size": 53687091200,
      "state": "ok",
      "message": ""
    }
  ],
  "env": {
    "SSH_KEY": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCXho85ijWqoqk3P+d4aBLs8K4wWowLnBx3mjo573Ey2yCXDO9Vx76cpoCvCW1kXKoDkVvy6OFbulKCVxYlF1rsgARCVYpHek5psnWi+TLjjnxFZcOWi8hZvveEVBE9Di59RxijGoZz//Gw4RqxzeaZJYPH/A6OdbqNvfb9/2kKQarN9LjL0dAozx5ZweCixlyzpOgiQeXbiHwkdHCI+X04lXbM4g4vgqIQ83Oh1iYlyr26IPmSz4MdbUj/B4NFFft+oV5JRn/1D35ANel+PHuI8mDKBEuK6YQ2CapC+D8oMn20fGr1Wd5NXYYJtonbID7iOUWfkR3fHkxM9nvqlk4DKSQgxEDhv38hyKrXfUmsVNioYkCMnLfScg7BD688Wxl/6pZa7QNCtTiJWXMxQux+mFw6E1Qd9toH4ncqk6TyC1VSBbvHPta5kHvHmrrKjcwUMBeumAU+emqO6oNxVYM7Brtjqaz6qdCi4ptL+HXqXgKatoPl3qY192PDqmwkEDk= pcone@pcone-computer",
    "MYSQL_USER": "admin",
    "MYSQL_PASSWORD": "X3#nTx%wZNfS",
    "ADMIN_EMAIL": "logismos@protonmail.ch",
    "WP_URL": "wp1.threefold.cfd"
  },
  "entrypoint": "/sbin/zinit init",
  "metadata": "",
  "description": "",
  "rootfs_size": 2147483648,
  "corex": false,
  "gpu": [],
  "deploymentName": "word0",
  "projectName": "wordpress/word0",
  "billing": "No Data Available",
  "wireguard": "[Interface]\nAddress = 100.64.20.3/32\nPrivateKey = FhffgAj3dEha2Qw9RhTJpLKMzlUbQ2E8rpZyXuVzBtw=\n\n[Peer]\nPublicKey = JQ1BulD14I0J606aIVkDdN+blzjo1EJsPB4m7XH6SUg=\nAllowedIPs = 10.20.0.0/16, 100.64.20.0/32\nPersistentKeepalive = 25\nEndpoint = 185.69.166.140:1890"
}
Mik-TF commented 6 months ago

More info from @scottyeager with the node 481 on mainnet with wordpress solution:

Seems the issue is that mysql didn't start on the node: image

Will advise the user to try on a different node and the farmer to check the node's health (same person actually).

scottyeager commented 6 months ago

I really don't think this is an issue with the Playground or the Wordpress image. Here's a copy of the log that MySQL printed when it crashed:

[+] mysql: 2024-04-24 17:15:14+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.0.34-1debian11 started.
[-] mysql: 2024-04-24 17:15:14+00:00 [ERROR] [Entrypoint]: mysqld failed while attempting to check config
[-] mysql:  command was: mysqld --datadir /var/lib/mysql_tmp --verbose --help --log-bin-index=/tmp/tmp.LSeWGHGCP5
[-] mysql:  2024-04-24T17:15:14Z UTC - mysqld got signal 11 ;
[-] mysql: Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
[-] mysql: BuildID[sha1]=957a7f933a999383cd4331a77a624f94708e2029
[-] mysql: Thread pointer: 0x0
[-] mysql: Attempting backtrace. You can use the following information to find out
[-] mysql: where mysqld died. If you see no messages after this, something went
[-] mysql: terribly wrong...
[-] mysql: stack_bottom = 0 thread_stack 0x100000
[-] mysql: /usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x3d) [0x559db33c1a3d]
[-] mysql: /usr/sbin/mysqld(print_fatal_signal(int)+0x393) [0x559db228a033]
[-] mysql: /usr/sbin/mysqld(handle_fatal_signal+0xa5) [0x559db228a0e5]
[-] mysql: /lib/x86_64-linux-gnu/libpthread.so.0(+0x13140) [0x7fac70d53140]
[-] mysql: /usr/sbin/mysqld(memory::Aligned_atomic<long>::Aligned_atomic()+0x6b) [0x559db305425b]
[-] mysql: /usr/sbin/mysqld(Delegate::Delegate(unsigned int)+0x53) [0x559db3054653]
[-] mysql: /usr/sbin/mysqld(delegates_init()+0x2e) [0x559db30547be]
[-] mysql: /usr/sbin/mysqld(+0xeddab6) [0x559db2015ab6]
[-] mysql: /usr/sbin/mysqld(mysqld_main(int, char**)+0x25ae) [0x559db201e39e]
[-] mysql: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7fac7085ed0a]
[-] mysql: /usr/sbin/mysqld(_start+0x2a) [0x559db1ffe3ca]
[-] mysql: The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
[-] mysql: information that should help you find out what is causing the crash.
[-] mysql: + mkdir -p /var/lib/mysql_tmp
[-] mysql: + chmod +x /usr/local/bin/sql_entrypoint.sh
[-] mysql: + cd /
[-] mysql: + ./usr/local/bin/sql_entrypoint.sh mysqld --datadir /var/lib/mysql_tmp

According to this line:

Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.

It seems mostly likely to be the hardware, since the issue is isolated to a single hardware system.