Hey there,

 

my server was running for many days without issues now, but now after swapping out a disk, to replace it with a bigger one, the GUI doesn't show. I've started the array with the encryption key and after I said start, the server shows this:

 

I had that problem before. Fixed it by rebooting. But I hope, that the new HDD is being rebuild and don't want to mess with that.

Does anyone have a fix?

 

Thanks in advance

Edited October 26, 20205 yr by pappaq

Try to get the diags by typing "diagnostics" in the console.

Doesn't work via putty 

Strange, what Unraid release? Try to get the syslog:

 

cp /var/log/syslog /boot/syslog.txt

 

Here it is: [here was an upload]

Edited October 26, 20205 yr by pappaq

Lots of nginx errors (also others but look unrelated), best bet is rebooting.

Ok, do I have an option to see how far the reconstruction of the array is without the GUI?

mdcmd status | egrep "mdResync"

It will display some values, including:
 
mdResync=total parity size
mdResyncPos=current position

 

If it's still going.

Thanks, works.

I've got the problem coming up again after rebooting and installing a SSD.

 

syslog.txt

 

Rebooting helps for around half an hour until it occures again.

3 minutes ago, pappaq said:

Rebooting helps for around half an hour

Can you get diagnostics then?

Actually it does not work. I'm getting "command not found" back, when I'm logged in via SSH.

All dockers are available and I am able to login to the server via SSH. I can't access the GUI and get:

 

Even when I try to enter just the ip after https://...

 

Also I get this one back in putty: 

 

The last time this occured I was able to solve it by simply rebooting. I've done so 3 times now. It comes back...

Have you tried booting in SAFE mode? With no dockers or VMs?

 

Do you have a flash backup?

 

 

14 minutes ago, trurl said:

Have you tried booting in SAFE mode? With no dockers or VMs?

 

Do you have a flash backup?

 

 

I have not tried that. Everything works except the GUI. Restarting nginx via etc/rc.d/rc.nginx restart didn't help either...

 

I've got a flash backup from march last year...that would be my last resort.

 

I opened this thread before that, so I guess it does not guarantee to solve the issue, because the current behavior occured before march last year.

 

Is there another way maybe? The server run 120 days after the last reboot without any issues...

 

 

Edited February 24, 20224 yr by pappaq

Is there a way to bring the "diagnostics" command back to life?

4 minutes ago, pappaq said:

I've got a flash backup from march last year

You must always keep a current backup of flash. Any configuration changes you have made in the webUI are stored on flash and any made since the last backup would be lost. Especially important that your flash backup have the correct disk assignments.

 

Put your flash drive in your PC and let it checkdisk. While there make a backup. Try again. If it still doesn't work you could make a new install and copy your config from the backup.

 

 

I thought I had installed a plugin which was configured to make frequent backups...didn't check it for a long time though.

 

Checked the flash drive and found no errors. Made a backup. Trying it again now.

 

Could you guide me to a tutorial to reinstall the flash drive?

Your configuration is completely in the config folder on flash. You just copy the config folder from your backup onto a new install.

Ok, I've reinstalled the flash drive and copied my config to it. Server back up and running. diagnostics is a command now...

 

I think I have never had a clean installation since I've started using unraid. And I changed the hardware and setups multiple times.

 

If the error occures again I will post the diagnostics. Thank you so much trurl for your support!

And we are back to square one. The bug is back. And strangely enough the diagnostics command is gone as soon as the bug occures.

 

I can provide the syslog.txt only...If nobody got a clue I will try to investigate next weekend.

 

After disabling netdata docker the "FastCGI sent in stderr: "Primary script unknown"" is gone and does not spam the logs. But now I see that nothing really indicates smth. strange in the logs that indicates the bug. Soooo I am going to try safemode etc. when I find the time and will report back here.

 

This fucking sucks and will cost so much time...

Edited February 25, 20224 yr by pappaq

Ok, everytime I try to load the GUI in any browser the following error occures in the syslog:

Feb 25 10:39:04 dringenet-MS nginx: 2022/02/25 10:39:04 [error] 23909#23909: *118637 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.1.195, server: , request: "GET /Main HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "cbc341bc4a11f139b471cdbe9e9ff76f4eeef8eb.unraid.net"
Feb 25 10:39:05 dringenet-MS nginx: 2022/02/25 10:39:05 [error] 23909#23909: *118637 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.1.195, server: , request: "GET /Main HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "cbc341bc4a11f139b471cdbe9e9ff76f4eeef8eb.unraid.net"
Feb 25 10:39:06 dringenet-MS nginx: 2022/02/25 10:39:06 [error] 23909#23909: *118637 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.1.195, server: , request: "GET /Main HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "cbc341bc4a11f139b471cdbe9e9ff76f4eeef8eb.unraid.net"
Feb 25 10:39:07 dringenet-MS nginx: 2022/02/25 10:39:07 [error] 23909#23909: *118637 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.1.195, server: , request: "GET /Main HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "cbc341bc4a11f139b471cdbe9e9ff76f4eeef8eb.unraid.net"
Feb 25 10:39:07 dringenet-MS nginx: 2022/02/25 10:39:07 [error] 23909#23909: *118637 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.1.195, server: , request: "GET /Main HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "cbc341bc4a11f139b471cdbe9e9ff76f4eeef8eb.unraid.net"
Feb 25 10:39:08 dringenet-MS nginx: 2022/02/25 10:39:08 [error] 23909#23909: *118637 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.1.195, server: , request: "GET /Main HTTP/2.0", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "cbc341bc4a11f139b471cdbe9e9ff76f4eeef8eb.unraid.net"

Does anybody got a clue?

You should have taken diagnostics when you could get them instead of waiting until you couldn't.

 

Does it work again for a while if you reboot?

Some of the last entries in syslog are about plugins and scripts, including a script you have apparently setup with the User Scripts plugin.

 

Boot in SAFE mode, disable Docker and VM Manager in Settings, and see if it works like that for a few days.

25 minutes ago, trurl said:

You should have taken diagnostics when you could get them instead of waiting until you couldn't.

 

Does it work again for a while if you reboot?

How should I have known that the command will vanish when the error occures? It normally returns to normal operation after the reboot.

 

Currently I've got no time to test. Furthermore my heating is automated via home assistant running on the server, making downtimes and disabling Dockers and VMs to my last resort.

 

I will try restarting and posting diagnostics then. Maybe you can review it then and tell if there is anything that indicates this kind of behavior.