jpfeifer14

When attempting to use the config template provided in the set up documentation, I consistently get this error in the logs Database connection failure: invalid integer value "=" for connection option "port" My odoo.conf is as follows:

This plugin appears broken on Unraid 7, any plans to update?

Proxied Cloudflare domains only handle HTTPS traffic, so RustDesk does not work over cloudflare tunnels.

@scolcipitato Thats very unfortunate, I loved that plugin

Does anyone have experience with this error: Some headers are not set correctly on your instance - The `Strict-Transport-Security` HTTP header is not set (should be at least `15552000` seconds)? Ive tried everything to make it go away. Cloudflare proxy both on and off, HSTS set in cloudflare to 6 months, HSTS set in Nginx Proxy Manager, and any combination of those options. When I use a web utility to check HSTS, it says that I have it enable and for far longer than the minimum in the error, but it still will not go away. Ive read about everything I can find and tried all possible solutions I've come across, so I am kind of at a loss here.

I finally caught the error as it was happening and was about to get the logs leading up to the repeating line. Jun 18 15:54:15 cloud kernel: usb 1-4: reset full-speed USB device number 4 using xhci_hcd Jun 18 15:54:15 cloud kernel: usb 1-4: reset full-speed USB device number 4 using xhci_hcd Jun 18 15:54:15 cloud kernel: cp210x 1-4:1.0: cp210x converter detected Jun 18 15:54:15 cloud kernel: usb 1-4: cp210x converter now attached to ttyUSB0 Jun 18 15:54:15 cloud kernel: cp210x 1-4:1.1: cp210x converter detected Jun 18 15:54:15 cloud kernel: cp210x 1-4:1.1: Failed to attach ACPI GPIO chip Jun 18 15:54:15 cloud kernel: usb 1-4: cp210x converter now attached to ttyUSB1 Jun 18 15:54:15 cloud usb_manager: Info: rc.usb_manager tty_add Silicon_Labs_HubZ_Smart_Home_Controller_6160034E /dev/ttyUSB0 Jun 18 15:54:15 cloud usb_manager: Info: rc.usb_manager tty_add Silicon_Labs_HubZ_Smart_Home_Controller_6160034E /dev/ttyUSB1 Jun 18 15:54:15 cloud kernel: usb 1-2.3: reset high-speed USB device number 7 using xhci_hcd Jun 18 15:54:15 cloud usb_manager: Info: rc.usb_manager Processing tty attach Silicon_Labs_HubZ_Smart_Home_Controller_6160034E /dev/ttyUSB0 Jun 18 15:54:15 cloud usb_manager: Info: rc.usb_manager Processing tty attach Silicon_Labs_HubZ_Smart_Home_Controller_6160034E /dev/ttyUSB1 Jun 18 15:54:15 cloud usb_manager: Info: rc.usb_manager Autoconnect No Mapping found Silicon_Labs_HubZ_Smart_Home_Controller_6160034E /dev/ttyUSB1 port Jun 18 15:54:15 cloud usb_manager: Info: rc.usb_manager Autoconnect No Mapping found Silicon_Labs_HubZ_Smart_Home_Controller_6160034E /dev/ttyUSB0 port Jun 18 15:54:17 cloud kernel: cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 Jun 18 15:54:17 cloud kernel: cp210x 1-4:1.0: device disconnected Jun 18 15:54:17 cloud kernel: cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1 Jun 18 15:54:17 cloud kernel: cp210x 1-4:1.1: Failed to retrieve ACPI GPIO chip Jun 18 15:54:17 cloud kernel: cp210x 1-4:1.1: device disconnected Jun 18 15:54:18 cloud kernel: usb 1-4: reset full-speed USB device number 4 using xhci_hcd Jun 18 15:54:19 cloud kernel: usb 1-4: reset full-speed USB device number 4 using xhci_hcd Jun 18 15:54:19 cloud kernel: cp210x 1-4:1.0: cp210x converter detected Jun 18 15:54:19 cloud kernel: usb 1-4: cp210x converter now attached to ttyUSB0 Jun 18 15:54:19 cloud kernel: cp210x 1-4:1.1: cp210x converter detected Jun 18 15:54:19 cloud kernel: cp210x 1-4:1.1: Failed to attach ACPI GPIO chip Jun 18 15:54:19 cloud kernel: usb 1-4: cp210x converter now attached to ttyUSB1 Jun 18 15:54:19 cloud kernel: cp210x ttyUSB0: cp210x converter now disconnected from ttyUSB0 Jun 18 15:54:19 cloud kernel: cp210x 1-4:1.0: device disconnected Jun 18 15:54:19 cloud kernel: cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1 Jun 18 15:54:19 cloud kernel: cp210x 1-4:1.1: Failed to retrieve ACPI GPIO chip Jun 18 15:54:19 cloud kernel: cp210x 1-4:1.1: device disconnected Jun 18 15:54:19 cloud usb_manager: Info: rc.usb_manager tty_add Silicon_Labs_HubZ_Smart_Home_Controller_6160034E /dev/ttyUSB0 Jun 18 15:54:19 cloud usb_manager: Info: rc.usb_manager tty_add Silicon_Labs_HubZ_Smart_Home_Controller_6160034E /dev/ttyUSB1 Jun 18 15:54:19 cloud kernel: usb 1-2.3: reset high-speed USB device number 7 using xhci_hcd Jun 18 15:54:19 cloud usb_manager: Info: rc.usb_manager Processing tty attach Silicon_Labs_HubZ_Smart_Home_Controller_6160034E /dev/ttyUSB1 Jun 18 15:54:19 cloud usb_manager: Info: rc.usb_manager Autoconnect No Mapping found Silicon_Labs_HubZ_Smart_Home_Controller_6160034E /dev/ttyUSB1 port Jun 18 15:54:19 cloud usb_manager: Info: rc.usb_manager Processing tty attach Silicon_Labs_HubZ_Smart_Home_Controller_6160034E /dev/ttyUSB0 Jun 18 15:54:19 cloud usb_manager: Info: rc.usb_manager Autoconnect No Mapping found Silicon_Labs_HubZ_Smart_Home_Controller_6160034E /dev/ttyUSB0 port Jun 18 15:56:21 cloud kernel: usb 1-4: usbfs: process 20431 (qemu-system-x86) did not claim interface 1 before use And then the last line repeats until the log fills and system crashes

It crashed the server, so I had to reboot. I looked for the historical log entries in the local log server, but the entire log was populated with the same error.

Unfortunately the backup syslog provided no extra context, just that same error repeating. The log history ended before it showed the start of the error.

Is there a way to at least maybe stop a crash from the log filling up? Can it be set to only retain a certain number of log entries? When the server crashes and Im out of town its a bit of a problem.

That was a past issue I had, I thought I had limited its ram usage. But the other day, and one other time this month, the error from my original post was filling the logs

cloud-diagnostics-20240514-2206.zip

Unraid is intermittently crashing because the log fills up with this error: May 13 12:00:00 cloud kernel: usb 1-4: usbfs: process 14474 (qemu-system-x86) did not claim interface 1 before use [4:50 PM] usb 1-4 is a zwave/zigbee controller attached to HA vm. Most of the time there is no issue, but occasionally it starts throwing back that error and the whole server crashes as a result of the Log filling up.

Is there anyway I can prevent the syslog from filling up and causing the system to crash from memory usage? Ive had a errors with a VM and a container recently that caused the log to fill up and crash the system. I fixed the errors, but I am worried about this happening with something else when I am out of town and unable to physically restart the server.

This appears to be an issue with the Frigate docker container so rapidly blowing through 128 GB of RAM that the system halts and never records an error, I have submitted a request on their github

Well, started adding back in services after no crashes in 48 hours. Ran the whole thing full force with a stress test on the cpu, all drives spinning, every container running and still only pulled 276w on the 750w psu, so Im kinda at a loss hardware wise. I guess it's not too late to RMA every component and pray it was one of those pieces.

So far, it has not crashed. At 48 hours Im going to start adding services back in, I have an idea that frigate might be causing it, although others have said that they actually get an "Out of memory" error when they have the issue Ive experienced, and I have not gotten that.

Still running with no crashes in safe mode 24 hours later so Im keeping an eye on it. I did stress test the CPU at one point with no crash, so theres that. I noticed that in safe mode the log repeatedly writes the following. I assume this is due to plugins being turned off but I wanted to make sure it isnt a bigger issue. Feb 24 14:21:43 cloud nginx: 2024/02/24 14:21:43 [error] 3667#3667: *876992 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 192.168.0.111, server: , request: "POST /plugins/dynamix.my.servers/include/unraid-api.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "192.168.0.11", referrer: "http://192.168.0.11/Dashboard"

Didnt think so. I have the server running in safe mode with only the array going, no VMs or docker. Issue takes about 24-48 hours to present so we'll see

Ok, Im setting it up in safe mode right now. It crashed again a bit earlier, so I pulled the latest logs, though I dont think this reveals any new information Feb 23 02:01:26 cloud emhttpd: read SMART /dev/sdb Feb 23 03:08:43 cloud emhttpd: spinning down /dev/sdb Feb 23 03:17:42 cloud emhttpd: read SMART /dev/sdb Feb 23 04:00:01 cloud emhttpd: read SMART /dev/sdi Feb 23 04:00:06 cloud emhttpd: read SMART /dev/sdg Feb 23 04:00:10 cloud emhttpd: read SMART /dev/sde Feb 23 04:17:57 cloud emhttpd: spinning down /dev/sdb Feb 23 05:01:37 cloud emhttpd: spinning down /dev/sdi Feb 23 05:02:45 cloud emhttpd: spinning down /dev/sdg Feb 23 05:02:45 cloud emhttpd: spinning down /dev/sde Feb 23 05:03:08 cloud sshd[17272]: Read error from remote host 192.168.0.111 port 62980: Connection timed out Feb 23 05:03:08 cloud sshd[17272]: pam_unix(sshd:session): session closed for user root Feb 23 06:12:50 cloud sshd[22939]: Connection from 192.168.0.111 port 52053 on 192.168.0.11 port 22 rdomain "" Feb 23 06:12:50 cloud sshd[22939]: Postponed keyboard-interactive for root from 192.168.0.111 port 52053 ssh2 [preauth] Feb 23 06:12:50 cloud sshd[22939]: Postponed keyboard-interactive/pam for root from 192.168.0.111 port 52053 ssh2 [preauth] Feb 23 06:12:50 cloud sshd[22939]: Accepted keyboard-interactive/pam for root from 192.168.0.111 port 52053 ssh2 Feb 23 06:12:50 cloud sshd[22939]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Feb 23 06:12:50 cloud sshd[22939]: Starting session: command for root from 192.168.0.111 port 52053 id 1 Feb 23 06:12:50 cloud sshd[22939]: Starting session: shell on pts/0 for root from 192.168.0.111 port 52053 id 0 Feb 23 06:12:50 cloud sshd[22939]: Close session: user root from 192.168.0.111 port 52053 id 1 Feb 23 06:12:50 cloud sshd[22939]: Starting session: command for root from 192.168.0.111 port 52053 id 1 Feb 23 06:12:50 cloud sshd[22939]: Starting session: command for root from 192.168.0.111 port 52053 id 2 Feb 23 06:12:50 cloud sshd[22939]: Close session: user root from 192.168.0.111 port 52053 id 1 Feb 23 06:12:50 cloud sshd[22939]: Close session: user root from 192.168.0.111 port 52053 id 2 Feb 23 08:28:28 cloud sshd[22939]: Read error from remote host 192.168.0.111 port 52053: Connection timed out Feb 23 08:28:28 cloud sshd[22939]: pam_unix(sshd:session): session closed for user root Feb 23 09:09:45 cloud emhttpd: read SMART /dev/sdg Feb 23 10:04:32 cloud emhttpd: read SMART /dev/sdd Feb 23 10:12:01 cloud emhttpd: spinning down /dev/sdg Feb 23 11:04:37 cloud emhttpd: spinning down /dev/sdd Feb 23 11:22:13 cloud sshd[11531]: Connection from 192.168.0.111 port 61662 on 192.168.0.11 port 22 rdomain "" Feb 23 11:22:13 cloud sshd[11531]: Postponed keyboard-interactive for root from 192.168.0.111 port 61662 ssh2 [preauth] Feb 23 11:22:13 cloud sshd[11531]: Postponed keyboard-interactive/pam for root from 192.168.0.111 port 61662 ssh2 [preauth] Feb 23 11:22:13 cloud sshd[11531]: Accepted keyboard-interactive/pam for root from 192.168.0.111 port 61662 ssh2 Feb 23 11:22:13 cloud sshd[11531]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0) Feb 23 11:22:13 cloud sshd[11531]: Starting session: command for root from 192.168.0.111 port 61662 id 1 Feb 23 11:22:13 cloud sshd[11531]: Starting session: shell on pts/0 for root from 192.168.0.111 port 61662 id 0 Feb 23 11:22:13 cloud sshd[11531]: Close session: user root from 192.168.0.111 port 61662 id 1 Feb 23 11:22:13 cloud sshd[11531]: Starting session: command for root from 192.168.0.111 port 61662 id 1 Feb 23 11:22:14 cloud sshd[11531]: Starting session: command for root from 192.168.0.111 port 61662 id 2 Feb 23 11:22:14 cloud sshd[11531]: Close session: user root from 192.168.0.111 port 61662 id 1 Feb 23 11:22:14 cloud sshd[11531]: Close session: user root from 192.168.0.111 port 61662 id 2

Any ideas what hardware issues I might look at? Memtest passed, and while i guess you can never rule out getting a brand new faulty motherboard, I find it strange that this one is running into the same issue that the other one did, only that one took a year to have the issue. I have a SAS card running a few drives, though Id assume that if something happened with that, it wouldnt kill the OS. The server has been set up on a LAGG connection since day one with no problems. As I said previously, even when the GUI cannot be reached, the system can be pinged. Other than that, I cannot think of anything hardware wise that changed recently. A surveillance drive was added as cache and a google coral was plugged in november, though these issues didnt arise until maybe January. I kept receiving a notification about MACVLAN being an issue so I changed it to ipvlan, but that didnt really seem to resolve anything. I believe the boot issue I was having is a quirk of the motherboard, it seems like if it is not cleanly shut down, occasionally it does not recognize the USB next boot, but will if power cycled.

The system quit responding again, so I had a look at the logs dont see anything in the last 12 hours or so that looked out of the ordinary. Really not sure what to make of this. Feb 21 00:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:40930 Feb 21 00:09:07 cloud emhttpd: read SMART /dev/sdi Feb 21 01:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:59164 Feb 21 01:14:01 cloud emhttpd: read SMART /dev/sdd Feb 21 01:56:40 cloud emhttpd: spinning down /dev/sdi Feb 21 02:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:38164 Feb 21 02:01:04 cloud emhttpd: read SMART /dev/sdb Feb 21 02:14:14 cloud emhttpd: spinning down /dev/sdd Feb 21 02:49:35 cloud emhttpd: read SMART /dev/sdi Feb 21 03:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:40484 Feb 21 03:01:19 cloud emhttpd: spinning down /dev/sdb Feb 21 03:33:18 cloud emhttpd: read SMART /dev/sdb Feb 21 04:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:41562 Feb 21 04:00:17 cloud emhttpd: read SMART /dev/sdg Feb 21 04:00:17 cloud emhttpd: read SMART /dev/sde Feb 21 04:08:41 cloud emhttpd: spinning down /dev/sdi Feb 21 05:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:54870 Feb 21 05:01:50 cloud emhttpd: spinning down /dev/sdg Feb 21 05:01:50 cloud emhttpd: spinning down /dev/sde Feb 21 05:31:36 cloud emhttpd: spinning down /dev/sdb Feb 21 06:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:38926 Feb 21 06:57:52 cloud emhttpd: read SMART /dev/sdi Feb 21 07:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:58790 Feb 21 07:57:57 cloud emhttpd: spinning down /dev/sdi Feb 21 08:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:40614 Feb 21 08:28:11 cloud emhttpd: read SMART /dev/sdd Feb 21 09:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:46250 Feb 21 09:28:16 cloud emhttpd: spinning down /dev/sdd Feb 21 10:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:60950 Feb 21 10:18:50 cloud emhttpd: read SMART /dev/sdi Feb 21 11:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:43262 Feb 21 11:27:13 cloud emhttpd: spinning down /dev/sdi Feb 21 12:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:58098 Feb 21 12:00:01 cloud Docker Auto Update: Community Applications Docker Autoupdate running Feb 21 12:00:01 cloud Docker Auto Update: Checking for available updates Feb 21 12:00:15 cloud emhttpd: read SMART /dev/sdi Feb 21 12:00:29 cloud Docker Auto Update: Found update for flaresolverr. Not set to autoupdate Feb 21 12:00:29 cloud Docker Auto Update: Found update for nextclouddb. Not set to autoupdate Feb 21 12:00:29 cloud Docker Auto Update: Stopping binhex-jackett Feb 21 12:00:33 cloud kernel: br-8133cdf1cf98: port 5(veth9cb7ff6) entered disabled state Feb 21 12:00:34 cloud kernel: veth3b3355e: renamed from eth0 Feb 21 12:00:34 cloud kernel: br-8133cdf1cf98: port 5(veth9cb7ff6) entered disabled state Feb 21 12:00:34 cloud kernel: device veth9cb7ff6 left promiscuous mode Feb 21 12:00:34 cloud kernel: br-8133cdf1cf98: port 5(veth9cb7ff6) entered disabled state Feb 21 12:00:34 cloud Docker Auto Update: Installing Updates for binhex-jackett Feb 21 12:00:47 cloud Docker Auto Update: Restarting binhex-jackett Feb 21 12:00:47 cloud kernel: br-8133cdf1cf98: port 5(veth4f5f4c8) entered blocking state Feb 21 12:00:47 cloud kernel: br-8133cdf1cf98: port 5(veth4f5f4c8) entered disabled state Feb 21 12:00:47 cloud kernel: device veth4f5f4c8 entered promiscuous mode Feb 21 12:00:49 cloud kernel: eth0: renamed from veth412ec51 Feb 21 12:00:49 cloud kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth4f5f4c8: link becomes ready Feb 21 12:00:49 cloud kernel: br-8133cdf1cf98: port 5(veth4f5f4c8) entered blocking state Feb 21 12:00:49 cloud kernel: br-8133cdf1cf98: port 5(veth4f5f4c8) entered forwarding state Feb 21 12:00:50 cloud Docker Auto Update: Community Applications Docker Autoupdate finished Feb 21 12:57:38 cloud flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup update Feb 21 13:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:47186 Feb 21 13:00:22 cloud emhttpd: spinning down /dev/sdi Feb 21 13:06:12 cloud emhttpd: read SMART /dev/sdi Feb 21 14:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:43620 Feb 21 14:06:16 cloud emhttpd: spinning down /dev/sdi Feb 21 14:15:56 cloud nginx: 2024/02/21 14:15:56 [alert] 6805#6805: worker process 21615 exited on signal 6 Feb 21 15:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:47458 Feb 21 15:13:40 cloud nginx: 2024/02/21 15:13:40 [alert] 6805#6805: worker process 6761 exited on signal 6 Feb 21 15:21:26 cloud emhttpd: read SMART /dev/sdg Feb 21 15:23:30 cloud emhttpd: read SMART /dev/sde Feb 21 16:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:42686 Feb 21 16:11:14 cloud emhttpd: read SMART /dev/sdb Feb 21 16:25:03 cloud emhttpd: spinning down /dev/sdg Feb 21 16:25:03 cloud emhttpd: spinning down /dev/sde Feb 21 17:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:38194 Feb 21 17:15:35 cloud emhttpd: spinning down /dev/sdb Feb 21 18:00:01 cloud usbipd: usbipd: info: connection from 192.168.0.11:59242

Thanks, Ive just started mirroring the logs to flash, Ill see if it happens again. Im going to be real PO'd if this new motherboard is bad as well

Over the last month, I have had issues with Unraid crashing and failing to reboot. When the system crashes, I am able to ping it but cannot reach the GUI or complete a connection via SSH. I can also not connect to the system directly as no video outputs to a monitor, although that may be because the default VGA was the video card, I have since switched to onboard so I can determine if that is still a problem in the future. Additionally, I was having an issue with the BIOS not recognizing the USB when I would go to reboot, until it was moved to another port. I have since purchased another usb and exchanged the mother board, as there was some question as to whether the USB ports on the board were failing, though Im having the same/similar issues. This most recent time, I was unable to determine if the USB disappeared completely on reboot, as I did not go direct to bios, however it did switch to network boot instead of the usb. When I went into the BIOS, the USB was there, though it was at the bottom of the list. I swear I had disabled other boots prior leaving only the usb, leading me to believe the USB disappeared entirely again, though I cannot be sure this time. This issue has persisted across 2 USBs and 2 motherboards, I am kind of running out of solutions. Possibly related, I have been running into an issue where certain crashes and reboots cause all of my docker containers to disappear.