502 bad gateway

Hello,

Seems like there is no such thing like complete happiness

I was so stoked that with your kind support I was getting everything running as a wanted when suddenly today i got a short power outage. I was not able to set up the UPS yet

and guess what: after booting up i got the famous 502 Bag gateway error when i tried to login. Everything else works. Just the Web GUI returns error.

I know this topic is pretty much all over the place but was not able to find a solution. I tried everything i was able to read.

I run OMV7 in a x64 hardware and use a USB flash drive along with openmediavault-flashmemory plugin. I have experienced the same effect a few times in the past as well only when USB drive is used for system drive

Could you help to me to come out of this situation please?

I have not completed the backup strategy yet so i am not sure a reliable backup is available either

sudo omv-salt deploy run nginx phpfpm

Have a look at the attachment. It got more than 10000 characters

sudo nginx -t

root@nas:~# sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
root@nas:~#

systemctl status php8.2-fpm.service

root@nas:~# systemctl status php8.2-fpm.service
× php8.2-fpm.service - The PHP 8.2 FastCGI Process Manager
     Loaded: loaded (/lib/systemd/system/php8.2-fpm.service; enabled; preset: enabled)
     Active: failed (Result: exit-code) since Fri 2024-03-08 17:13:30 EET; 1s ago
       Docs: man:php-fpm8.2(8)
    Process: 17210 ExecStart=/usr/sbin/php-fpm8.2 --nodaemonize --fpm-config /etc/php/8.2/fpm/php-fpm.conf (code=exited, status=78)
    Process: 17211 ExecStopPost=/usr/lib/php/php-fpm-socket-helper remove /run/php/php-fpm.sock /etc/php/8.2/fpm/pool.d/www.conf 82 (code=exited, status=0/SUCCESS)
   Main PID: 17210 (code=exited, status=78)
        CPU: 36ms

The result from journalctl -xeu php8.2-fpm.service is an empty log.

I appreciate your effort.

I am just thinking.

Being a common issue is it clear what exactly is the broken part? Isn't it possible to create a rescue entry on omv-firstaid to be able to recover it somehow.

Of course it is always better to make a backup of the os disk but stll

Here is a question. I do have the kernel plugin and as far as i remember i have also downloaded clonezila iso. How could i force my nas to boot fro clonezila iso. I found a not that old dd-full-disk usb image i made so i can try to recover it headlessly.

At least let me take the advantage of the situation and try to deal with a real recovery process scenario

I also see a huge benefit in such option being available through the omv-firstaid. Boot clonezila option in the menue

Zitat

In System>Kernel press the Clonezilla button, then press the Reboot to Clonezilla once button.

Do not have access to gui. Can i do that through ssh

I was eventually able to restore my OS drive.

But got something else in trying to restore containers through the compose plugin

I use volume binds for docker and containers. Now with my restored system i wanted to use all the benefits of the compose plugin and restore my latest compose files/volumes.

The restore process was successful. When i inspected the compose files using the "check" i can see the latest and changes was definitely restored as is from the backup folder. However the compose file content for the same container in the editor compose->files->container shows still the old content as before the restoration process.

Here is an example for nodered container:

"check" options shows after restoring the container

name: nodered
networks:
  default:
    name: nodered_default
  iot:
    external: true
    name: iot
services:
  node-red:
    environment:
      - TZ=Europe/Sofia
    image: nodered/node-red:latest
    networks:
      iot:
        ipv4_address: 192.168.10.33
    ports:
      - mode: ingress
        protocol: tcp
        published: "1880"
        target: 1880
    restart: unless-stopped
    volumes:
      - bind:
          create_host_path: true
        source: /containers-data/nodered
        target: /data
        type: bind
version: "3.7"

the editor for the same container shows

version: "3.7"

services:
  node-red:
    image: nodered/node-red:latest
    environment:
      - TZ=Europe/Sofia
    ports:
      - "1880:1880"
    volumes:
      - /containers-data/nodered:/data
    restart: unless-stopped

Initially i have created the container with the compose as in the second example but later on i have manually added the network section so the compose should definately look like the first text section. But is the old one

Also i tried to import a compose file which is not listed in the compose->files but it did not appear

Do i have to reload the compose plugin somehow. Tested with cleaning up the browser but it did not help

I have not modified anything through the CLI.

1. The system image i was able to restore with clonezila had already a few containers created entirely with the compose plugin GUI a few days before the "502 bad gateway" situation.

2. The current installation (with the login issue) was working a few days more after it was backed up to the image from point 1. For that a few days i have modified the compose files entirely and only using the compose plugin.

3. My docker folder , compose folder, persistent data folder and backup folder a located on another nvme drive

4. When i restored the broken system disk with the backup one, the compose files in the compose->files gui were shown as there were created in the old backup image so I decided to restore my compose folder, persistent data folder from the backup folder in order to update the compose files in the already restored system drive with the latest actual once

5.The restore process was successful but the compose files were never updated

The problem in my opinion is not the backup process itself because the compose folder was not affected in the backup/restore process anyway. It contents remain unchanged through the entire process.

It seems like the memory where the compose file keeps its data for the compose files was not refreshed after the backup process was completed. Instead it remained like it was set in the old backup image. The compose data base has to be refreshed in my opinion

Zitat

Therefore, the changes you make to a container must be made in the plugin's GUI.

The changes were always made in the compose gui but in different system installations - the current one and the backup image

I tried to use the import feature and pointed out a container from my compose folder. I was expecting that this would force the omv database to be updated but the container did not appear

Zitat

So what I would do, if it's not 200 :), is simply open each file in CLI (or with putty) to copy and paste the configuration in the GUI in each compose file.

I could do that but what it the backup process meant to do than. What if i had to make a brand new installation and wanted to restore my container setup from another drive that has been backed up. I restore process will never be possible. It more like a backup without an option for restoring