hawihoney

This is the second time I try to compile something on Unraid and I do get this error in Make. What is 'as' (Assembler?) and how can I install that on Unraid? cc: error trying to exec 'as': execvp: No such file or directory Any help is highly appreciated. Thanks.

I'm using this XMLRPC-Client to send "Start/Stop downloads" commands from Tautulli to another Unraid docker container: https://gist.github.com/bjoern-r/c3afda16d45edad5f4a5 The last two lines of this script look like this: curl -k $verbose --data "@$rpcxml" "$servUrl" 2>/dev/null | xmllint --format - \rm -f $rpcxml xmllint is not part of Unraid so I removed the pipe: curl -k $verbose --data "@$rpcxml" "$servUrl" 2>/dev/null \rm -f $rpcxml I was under the impression, that "\rm $rpcxml" would remove the temporary xml file in $rpcxml. That does not work. Every RPC request leaves the temp file in the directory. Any help is highly appreciated.

OMG, it was that easy. Had to put "sleep 5s" in script between docker start (mariadb, nextcloud) and before calling mysqldump. Thank you very much.

I do have MariaDB running in a docker container. I would like to take a backup of all databases every night with the help of the user scripts plugin. Whatever I try, it doesn't work. This is the last iteration of my tests. If I call it from the console it works perfect. Running from user scripts fails: docker exec mariadb /usr/bin/mysqldump --user=root --password=******** nextcloud > /mnt/user/data/mariadb_backup/nextcloud/dump.sql Here's the complete MariaDB/Nextcloud backup script with the failing line: #!/bin/bash #arrayStarted=true #clearLog=true #noParity=true docker stop nextcloud docker stop mariadb rsync -avPX --delete-during /mnt/cache/system/appdata/mariadb/ /mnt/user/data/appdata_backup/mariadb/ rsync -avPX --delete-during /mnt/cache/system/appdata/nextcloud/ /mnt/user/data/appdata_backup/nextcloud/ rsync -avPX --delete-during /mnt/cache/NextCloud/ /mnt/user/data/nextcloud_backup/ rsync -avPX --delete-during /mnt/cache/NextCloud/hawi/files/.Contacts-Backup/ /mnt/user/data/nextcloud/contacts/ docker start mariadb docker start nextcloud # Does not work # docker exec mariadb /usr/bin/mysqldump --user=root --password=******** nextcloud > /mnt/user/data/mariadb_backup/nextcloud/dump.sql I even tried to but "sudo" in front of it - no joy. I'm out of ideas. Is there really no way to take a backup of a MariaDB database with user scripts? Many thanks in advance.

Is it possible to send commands to Unraid like Start/Stop Parity Check via RPC (e.g. XML-RPC)? If yes, how? If no, are there other methods to send commands to Unraid? Many thanks in advance.

Thanks.

Thanks for your answer. What puzzles me is that it happened during start of the first parity check (non-correctional). This one was immediately canceled. The then re-started parity check (correctional) does not mention any problems at all. BTW: It's a LSI 9300-8e HBA connected to a Supermicro BPN-SAS2-846EL1 backplane. I guess, if the correctional parity check comes to a successful end I simply can ignore these 3x128 errors in the error column?

Today I did start a non-correctional parity check on a dual parity array. Within the first 5 GB Unraid did report three disks with read errors (128 each) but did go on with the parity check. I immediately canceled the non-correctional parity check. After that I did start a correctional parity check. This correctional parity check went thru the first 5 GB without any warnings/errors. What's the status? The read errors just happened once? Why? The disks in question don't show any SMART problems. Something I need to worry about? Many thanks in advance. Diagnostics attached. towervm01-diagnostics-20190703-0700.zip

All three machines back to 6.7.0 now. Everythings good. Sorry for my frustrated Post.

Yes, two NVMe building a cache. Each on its own PCIe x4 card.

We're running plugins, dockers AND VMs. I wrote that in the answer to your post. No need to discuss descisions that happened in the past. It was running perfect. But I will change some things, definetely.

Yes, I do see that now. Three events occured at the same time. I never thought about this: * SQLite was thrown out in 6.7.1 and put back in 6.7.2. * Unraid NVIDIA 6.7.2 release is delayed. * In addition, lots of security patched have been applied since 6.7 As I wrote above. I'm still learning. I will change that, definetely.

We have tons of self written scripts that create, manipulate and extract databases (MariaDB and SQLite). Many of them running automatically from within Unraid User Scripts. Some PHP, some Perl, some bash, ... There's for example a 30GB SQLite database that simply holds personal names and their relations. MariaDB is running here as well, but for some jobs it's not fast enough. Running that same, identical 30GB database on MariaDB was a pain - slow as hell. We thought it would be a good idea to put everything from Windows onto the Unraid server and use the infrastructure of plugins, dockers and VMs. I didn't expect to fall into such a hole. 40 years of software development and I'm still learning. For me it seems that there's much manual activity envolved when maintaining a plugin such Unraid NVIDIA. I was under the impression that these tasks are mainly automated. As I said. I'm still learning. Here's one of the dumps that is failing since 6.7.1. Boom, without notice. echo ".dump" | sqlite3 /mnt/cache/system/appdata/SQLite/Similar/similar.db > /mnt/user/Data/sqlite_backup/Similar/dump.sql

As a user of Unraid NVIDIA _and_ tools using SQLite the delayed 6.7.2 Unraid NVIDIA release is a real problem here. We can't change back to stock Unraid. On the other side some important SQLite based tools don't work any longer. In fact it has bitten us because after applying 6.7.1 SQLite tools and SQLite dumps did overwrite backups with empty files. We simply did not expect that somebody would remove a tool like SQLite from Unraid. Now Unraid 6.7.2 is out and SQLite is back - but not for us. We have to wait for the Unraid NVIDIA 6.7.2 release. Going back to 6.7.0 without these additional security patches is no option either. So now we have lot of time to change our own SQLite tools to check for SQLite in Unraid before dumping data or whatever. New data is not coming into the house - so everything cool, no? Just some other 0.02 USD.

I do restart and backup all docker containers every night with User Scripts. So there's a User Script for each and every docker. I had to move the start of the User Scripts to a different time in the night but that was easy enough (crontab -e). docker stop <containername> # Backup tasks depending on specific docker containers # e.g. rsync user content to backup machine # e.g. cp settings to backup machine (e.g. Plex watch state and settings) # e.g. dump or export database contents (e.g. MariaDB, SQLite, ...) # e.g. ... docker start <containername> After these scripts are being started every night I no longer experienced any problems. Specific conditions would be cool, but if you start to collect conditions it will become a can of worms IMHO. RAM usage Port not responding + Plex activity from remote users (won't restart and backup Plex if there is streaming activity) + Running parity check on remote backup server (won't backup if a parity check is running) ... You get the idea. The possible conditions are nearly endless.