• Posts

  • Joined

  • Last visited

Everything posted by xthursdayx

  1. I'll contact Steef about it to make sure he's planning to update the core image. If not, I'll roll my own and update here. I'll report back here once I know though. Edit: the necessary libraries are already installed in this image, so no changes are necessary. This has already been tasted by someone running the beta update. Please see this Github issue for more info. Cheers!
  2. Yep, the issue is due to their being two approved templates for the same image in CA. Squid will have to decide which one to remove, and then you should no longer see this error in the Fix Common Problems plugin. In the meantime, you shouldn't worry about this error as it shouldn't impact your ability to use your Whoogle-search contiainer. Apologies if you added your template first @FoxxMD. I added mine because I didn't see one in CA and was using Whoogle myself, so I figured I'd share UNRAID my template, but it's possible that you'd already added yours by the time that mine updated in CA.
  3. As @Squid mentioned above, this is because both FoxxMD and I created templates for the same image. I think he's removed mine now, but I'm not sure as I'm out of town and can't check my UNRAID server at the moment. My best suggestion is to check CA and see which Whoogle template is listed, and then use that one.
  4. Yeah, you're right, I should have included that. I checked /var and it was not full. See: df -h /var Filesystem Size Used Avail Use% Mounted on rootfs 32G 7.0G 25G 23% / However /var/log does show as 100% full: ❯ df -h /var/log Filesystem Size Used Avail Use% Mounted on tmpfs 128M 128M 0 100% /var/log I deleted syslog.1 and syslog.2, restarted nginx and tailed my syslog. No more nchan out of memory errors, but I'm getting this error constantly: nginx: 2021/09/17 16:53:47 [alert] 2815#2815: worker process 11259 exited on signal 6
  5. I've just started running into this issue as well, on a machine running unRAID 6.10.0-rc1 with 64Gb of memory, which has always been plenty, though I too am guilty of leaving unRAID WebUI tabs open (as well as mosh/ssh sessions running). Interestingly, I'm able to access the pages of the WebUI and see the header and nav buttons, as well as the major sections of pages like the Dashboard and Main, however they're empty, not showing my disks, docker containers, etc. The only way I've been able to (temporarily) “fix” the issue is by restarting my server. I tried restarting /etc/rc.d/rc.nginx/, but it didn't make any difference, as you can see in these logs: Sep 17 02:25:29 vulfTower nginx: 2021/09/17 02:25:29 [alert] 25209#25209: worker process 32623 exited on signal 6 Sep 17 02:25:29 vulfTower nginx: 2021/09/17 02:25:29 [alert] 25209#25209: worker process 32645 exited on signal 6 Sep 17 02:25:31 vulfTower nginx: 2021/09/17 02:25:31 [alert] 25209#25209: worker process 32647 exited on signal 6 Sep 17 02:25:31 vulfTower nginx: 2021/09/17 02:25:31 [alert] 25209#25209: worker process 334 exited on signal 6 Sep 17 02:25:31 vulfTower nginx: 2021/09/17 02:25:31 [alert] 25209#25209: worker process 339 exited on signal 6 Sep 17 02:25:32 vulfTower nginx: 2021/09/17 02:25:32 [alert] 25209#25209: worker process 350 exited on signal 6 Sep 17 02:25:33 vulfTower nginx: 2021/09/17 02:25:33 [alert] 25209#25209: worker process 405 exited on signal 6 Sep 17 02:25:33 vulfTower nginx: 2021/09/17 02:25:33 [alert] 25209#25209: worker process 565 exited on signal 6 Sep 17 02:25:33 vulfTower nginx: 2021/09/17 02:25:33 [alert] 25209#25209: worker process 591 exited on signal 6 Sep 17 02:25:34 vulfTower nginx: 2021/09/17 02:25:34 [alert] 25209#25209: worker process 594 exited on signal 6 Sep 17 02:25:34 vulfTower rsyslogd: file '/var/log/syslog'[2] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2102.0 try https://www.rsys log.com/e/2027 ] Sep 17 02:25:34 vulfTower rsyslogd: action 'action-0-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2102.0 try https:/ /www.rsyslog.com/e/2027 ] Sep 17 02:25:34 vulfTower rsyslogd: rsyslogd[internal_messages]: 561 messages lost due to rate-limiting (500 allowed within 5 seconds) Sep 17 02:25:34 vulfTower rsyslogd: file '/var/log/syslog'[2] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2102.0 try https://www.rsys log.com/e/2027 ] Sep 17 02:25:34 vulfTower rsyslogd: action 'action-0-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2102.0 try https:/ /www.rsyslog.com/e/2027 ] ad infinitum I'm also getting these errors in my logs: Sep 17 02:32:54 vulfTower nginx: 2021/09/17 02:32:54 [alert] 25209#25209: worker process 4936 exited on signal 6 Anyway, I tried running du to check my log sizes as well as df to check how full my cache drives and boot flash drive are, to see if I could identify the issue. You can see the results below. While my NGINX and Syslog are large, neither seem to be large enough to disable access to the WebUI, and neither of my cache drives (where I store my syslog backup). ❯ du -sh /var/log/* 4.0K /var/log/apcupsd.events 0 /var/log/btmp 0 /var/log/cron 0 /var/log/debug 88K /var/log/dmesg 1012K /var/log/docker.log 0 /var/log/faillog 2.8M /var/log/file.activity.log 16K /var/log/gitflash 4.0K /var/log/lastlog 4.0K /var/log/libvirt 4.0K /var/log/maillog 0 /var/log/messages 0 /var/log/nfsd 52M /var/log/nginx 0 /var/log/packages 0 /var/log/pkgtools 0 /var/log/plugins 0 /var/log/preclear.disk.log 0 /var/log/pwfail 0 /var/log/removed_packages 0 /var/log/removed_scripts 0 /var/log/removed_uninstall_scripts 20K /var/log/samba 0 /var/log/scripts 0 /var/log/secure 0 /var/log/setup 0 /var/log/spooler 0 /var/log/swtpm 69M /var/log/syslog 3.6M /var/log/syslog.1 0 /var/log/vfio-pci 8.0K /var/log/wtmp ❯ df -h /mnt/cache Filesystem Size Used Avail Use% Mounted on /dev/sdf1 466G 306G 157G 67% /mnt/cache ❯ df -h /mnt/cache_io Filesystem Size Used Avail Use% Mounted on /dev/sdk1 932G 244G 688G 27% /mnt/cache_io ❯ df -h /boot Filesystem Size Used Avail Use% Mounted on /dev/sda1 7.5G 893M 6.6G 12% /boot Any ideas? For some reason, I'm currently unable to download my diagnostics, but any advice or ideas would be much appreciated. Cheers!
  6. That’s very alarming @xrqp! Glad you were able to resurrect your lost data last time and hope you’ll be able to again. My guess would be that problem is your harddrives or something about how your unRAID shares are set up. I’ve never had this problem or heard of anyone having it in relation to Roon. Sorry not to be of more help, but best of luck. And definitely let us know if you do end up finding some connection to Roon. I’ve already been working on either making a new base image or adding a PR to Steef’s, so it’s a good time if some work needs to be done.
  7. Interesting, I've been having some instability and temp issues recently and now I'm wondering if it has to do with the flashed Dell PERC H310 I have my server right now. In terms of the PIKE 2308 card, did you just follow the same directions cited above for the 2008 card? Or did you run into any differences? BTW, thanks for replying, despite the necro-thread!
  8. I realize this is raising a post from the depths of death, but I was wondering if you were ever able to get one of those PIKE 2308 cards flashed and working @Dextros?
  9. Also, thanks a lot for this, I'm using this (with the appropriate link, of course) as part of an existing script to install neofetch at the start up of the array, since the package NerdPack doesn't seem to work.
  10. I'm still having this same issue with neofetch on the latest version of unRAID. The NerdPack interface shows neofetch-20200708-noarch-1.txz as downloaded but not installed, and my syslog shows "nerdpack: Installing neofetch-20200708 package..." while every other package I have installed says something like "perl-5.32.0 package up to date, checksum ok." Any ideas why it won't actually install?
  11. I'd also love to see the shell (bash, zsh, whatever), profile (.bashrc, .zshrc, etc), and fonts be more customizable as well... I've got some scripts running that help with this, but it'd be nice if was a little more easily customizable.
  12. Yeah, both ferdi and ferdi-server are under active development. I'm planning to begin working again on ferdi-server-docker soon, once I I finish up another project. Glad you were able to find the things you were looking for though!
  13. Thanks for point that out @sonic6! I'll soon be active development on the server docker again, so I'll be sure to update you @ich777 if anything I change should cause breakages.
  14. It's not a huge issues, but I was wondering if there is a way to change the plugin header background transparency? Or change the color? I searched the thread, and wasn't entirely sure I understood the posts relating to "color". Thanks for the help! Edit: don't mind me, I'm just an idiot and was trying to adjust the header background colors in the theme engine rather than in display settings.... Carry on!
  15. Which services are you speaking about? The ferdi-server docker image (which I developed) just runs the existing release of ferdi server, so it should be up to date with any additional work that's been done on the server (I haven't been working directly on the server repo lately, so I'm not totally up to date with the developments there). There is not a Docker image for Ferdi itself, meaning the actual front-end UI program, since that is usually installed directly on the end user's machine. I suppose one could build a Docker image based on No-VNC or Guacamole in order to have Ferdi run on your server and be accessible via WebUI, but this isn't something I've worked on.
  16. Yep, all that clicking "yes" will do will update the link to my Roon Unraid Template .xml, it won't actually change the settings you already have in your template. But you can ignore it as well, shouldn't make any difference as the changes I made were purely organizational any way. I'll always update here if it's necessary to make any major template changes.
  17. It seems you're reading that warning message incorrectly... in my template the "Docker Hub URL" points to steefdebruijn's image, because he maintains the image and I haven't seen any need to fork it. The warning is telling you that the TEMPLATE URL (not Docker Hub url) of your current docker container is different than that specified by the author (me). That message is just the result of me updating my docker template repo files, which then updates them in Community Apps. You can apply the fix or not, it doesn't really matter, since I didn't actually change the template itself, just the organization of my repo. That fix also doesn't have anything to do with the other issues you're experiencing. Unfortunately, I'm not still not sure what to tell you regarding the issue you're having, particularly given that things seemed to work for you after a reboot. I will say that I run emby on a non-native port while running roon on its native ports and haven't run into any issues myself.
  18. I'm not sure why Roon would have a conflict with Emby at 1900... When I had an issue with port conflicts it was because I was using a port in the range mentioned above. To quote the another, more recent post (from last month) from the Roon forums discussing Roon's port use: ^ That post was specifically about firewall routing obviously, but is in agreement with the post from 2015 that I quoted above from Brian, Roon's CTO. It could be that the issues you're having relates to Roon's need to use multicast, but I'm not sure. Until anyone else runs into this issue it will be a bit difficult to troubleshoot. I'll be of any help that I can though.
  19. According to the Roon community forums, Roon uses Port 9003/UDP and Ports 9100-9200/TCP. Unfortunately, I don't know of any way to change this. That's because, although you can remap the Roon Server Docker ports to different host ports, I don't know of any way to change the ports that Roon clients (on your endpoints and controller devices) use to search for a local Roon CORE. I also ran into this same issue when first starting to use Roon but just ended up having to remap other things and let Roon use its native ports.
  20. YACReaderLibraryServer Docker Headless version of the YACReaderLibraryServer, running on a custom base image built with Ubuntu 18.04 LTS cloud image and S6 overlay. YACReader is the best comic reader and comic manager available, with support for cbr, cbz, zip, and rar comic files. YACReaderLibraryServer makes it easy to run a home comics server to serve your comics to any device running a YACReader client (including Windows, MacOS, and Linux as well the YACReader iOS app. Setup Instructions You can choose to install one of two versions of the YACReaderLibraryServer docker image, which use two different compression backends - either p7zip or unarr. These two versions are handled via the Docker repository tags "xthursdayx/yacreaderlibrary-server-docker:pzip" or "xthursdayx/yacreaderlibrary-server-docker:unarr" in your docker settings. For the best stability and general quality, it is recommended that you install YACReaderLibraryServer with unarr, which is the default installation. It should be noted, however, that as of version 1.0.1, unarr supports fewer formats than p7zip, notably RAR5. There is also some evidence that YACReaderLibraryServer compiled with p7zip may scan and create your comic library(s) faster than the version complied with unarr, so the choice is yours. In practice, any shortcomings unarr has are rarely an issue, since the vast majority of comic books use either zip or RAR4 compression, which is handled nicely by this backend, and after the initial library creation, library updates proceed smoothly with either decompression backend. If you would like to use the default unarr backend, then you do not need to add any tag to "xthursdayx/yacreaderlibrary-server-docker` since it will default to the "latest"/"unarr" tag. The docker images are also available from the GitHub container registry: ghcr.io/xthursdayx/yacreaderlibrary-server-docker Here are some examples to help you get started creating a container from this image. If you are an UNRAID user you can access my UNRAID YACReaderLibraryServer template which is available in Community Apps. Docker CLI docker run -d \ --name=YACReaderLibraryServer \ -e PUID=99 \ -e PGID=100 \ -e TZ=America/New_York \ -p 8080:8080 \ -v /path/to/config:/config \ -v /path/to/comic:/comics \ --restart unless-stopped \ xthursdayx/yacreaderlibrary-server-docker:[tag] ### docker-compose --- version: "2.1" services: yacreaderlibrary-server-docker: container_name: YACReaderLibraryServer image: xthursdayx/yacreaderlibrary-server-docker:[tag] environment: - PUID=99 - PGID=100 - TZ=America/New_York volumes: - /path/to/config:/config - /path/to/comics:/comics ports: - 8080:8080 restart: unless-stopped Parameters Container images are configured using parameters passed at runtime (such as those listed above). These parameters are separated by a colon and indicate <external>:<internal> respectively. For example, -p 8080:80 would expose port 80 from inside the container to be accessible from the host's IP on port 8080 outside the container. You can change the external/host port and volume mappings to suit your needs. | Parameter | Function | | :----: | --- | | `-p 8080` | HTTP access to YACReaderLibraryServer. | | `-e PUID=99` | for UserID - see below for more information. | | `-e PGID=100` | for GroupID - see below for more information. | | `-e TZ=America/New_York` | Specify a timezone to use, e.g. America/New_York. | | `-v /config` | Directory where YACReaderLibraryServer's configuration and log files will be stored. | | `-v /comics` | The directory where YACReaderLibraryServer will look for your comics. | | tag |(Optional) The docker tag will pull your chosen version YACReaderLibraryServer, the options are pzip or unarr/latest (default). | User / Group Identifiers When using volumes (-v flags) permissions issues can arise between the host OS and the container, you can avoid this by specifying the user PUID and group PGID. Ensure any mapped volume directories on your host machine are owned by the same user you specify and you will avoid any permissions issues. In this instance PUID=99 and PGID=100, to find yours using the following command: $ id <username> # Replace with your username uid=99(nobody) gid=100(users) groups=100(users) Usage Instructions To create a new YACReader comics library run the following command from the CLI on your host machine, changing `<library-name>` to whatever you want your library to be called: docker exec YACReaderLibraryServer YACReaderLibraryServer create-library <library-name> /comics To add an existing YACReader library: docker exec YACReaderLibraryServer YACReaderLibraryServer add-library <library-name> /comics To update your YACReader library (e.g. when you've added new comics): docker exec YACReaderLibraryServer YACReaderLibraryServer update-library /comics To list all existing YACReader libraries: docker exec YACReaderLibraryServer YACReaderLibraryServer list-libraries To remove a YACReader library: docker exec YACReaderLibraryServer YACReaderLibraryServer remove-library <library-name> Accessing YACReaderLibraryServer You can access your YACReaderLibraryServer by pointing your YACReader app to: `http://SERVERIP:8080` (Replace `SERVERIP` with the correct value). Please note: YACReaderLibraryServer does not have authentication installed by default, so it is not advisable to expose your server outside of your home network. If you wish to be able to access YACReaderLibraryServer from outside your local network please use a reverse ssl proxy, such as NGINX with an .htaccess file, or a locally-hosted VPN, such as OpenVPN to access your local network. If you appreciate my work please consider buying me a coffee, cheers! 😁
  21. Yep, I’ve done it and it worked fine. I’m happy to help work out any issues should they arise in the future, but, to the best of my knowledge, internal CORE updates have been stable for a while now.
  22. You have to update from within the Roon app running on your computer or other device. Through the app you can update both the locally running Roon software as well as the Roon CORE running in this Docker container.
  23. No problem. The other option (though also not ideal) would be to set up an SMB share for your comics directory on your unRAID machine and then run YACReaderLibrary on your main computer with the comics directory set to that network share. You might run into problems if you accidentally start YACReader/YACReaderLibrary with the network share disconnected, but it should work otherwise.