kharntiitar

Did you ever resolve the issue?

Here is a short script that reboots nginx every hour. I wanted it to run in a screen/tmux session so that *hopefully* when the next update comes out the issue is resolved, and the subsequent reboot will stop the script. if not, I just manually run it again, until the next version... I don't think I'll notice nginx rebooting every hour, but if it becomes an issue, I can always stop it and change the sleep time. #!/bin/bash # Endless loop while true; do # Kill nginx processes forcefully pkill -9 nginx # Start nginx /etc/rc.d/rc.nginx start # Sleep for one hour before next iteration. sleep 1h done

Another thank you for this workaround. I'd love to find out a reason for it happening, it just suddenly started for me about 2 weeks ago.

Hey @Infotrend Inc., thanks for getting back to me so fast, sorry I failed to achieve the same. You were 100% correct on it being an environmental variable. I had, in my haste to get it setup, set the value of "OAIWUI_SAVEDIR" to the path of a host folder, rather than correctly to "/iti". I have no idea how I missed this, but stepping away for a couple of weeks has helped me work it out I think this is what is causing my ongoing issue, I use a MACVLAN network for my unraid containers, so my IP isn't the same as my unraid install. Either that or I've misconfigured something.

Hey there, I've spent a while trying to get this working, but I'm not having much success. Maybe you can advise, @Infotrend Inc.?? The container boots fine, but when I go to the web interface, I get a blank dark blue screen. there's a ... menu on the top right, and I can go to settings there. there is "made with streamlit" down on the bottom left and there's a gradient from red to yellow across the top. I've tried a couple of different browsers and computers, and I get the same result.. Also, when I refresh, for just a microsecond there's a box that pops up, which says "please wait". I've got no errors in the logs. Also, as a minor side note.. any chance you can allow reverse proxies, or a variable for the url?

Just to continue with the permissions thing, I too am having this issue, for a few months now. I have umask set to 000, and it creates folders fine: drwxrwxrwx 1 nobody users 50 Dec 5 14:40 Some_Folder_Name but the files that are extracted aren't so great: -rw-r--r-- 1 nobody users 260M Jun 26 2021 some_file_name.mkv I have a script that runs via cron to chmod the files, once they have permissions of 777, sonarr/radarr etc.. will pick up the file within a few seconds. .. But this isn't really an ideal solution. Folders all the way back to /mnt/user/Downloads are permission 777. script is just: chmod -R 777 /mnt/user/Downloads/Complete

Hey again @GonjaT! Eep! sorry, I (obviously) didn't read the first post and just went straight to requesting. Thank you very much, I really do appreciate it!

Hey @GonjaT I was wondering if you'd be willing to make another mc server image? My friend has been telling me about this server he has been playing on which is running 'Ragnamod VI' and it sounds pretty cool .. Of course I have no idea how difficult that will be, but if it's not too crazy, I'd really appreciate it ❤️

Hi there, would there be any chance on adding 'Progress' to the pack? https://www.mankier.com/1/progress https://slackbuilds.org/repository/15.0/system/progress/ ❤️

Thanks @Dave001 for this resolution workaround... I just ran in to this after updating for the first time in a long while... It frustrates me how many people respond with "don't use the internal, install this overcomplicated method instead!" .. I am the only person that has access to my Unraid server, and it doesn't have any outside access. I use the very basic vsftpd implementation to transfer files between my local PC and my local server .. I have no need for SFTP overheads, or running another docker or plugin, what's there is good enough. IMHO, just because some people may use it insecurely doesn't mean that all of us should be forced to have the inconvenience of using workarounds for a setting that, as you mentioned previously, has worked fine for the last 10+ years... Sure, make it disabled by default, but if I change a setting it should stick, even after reboots.

Oh yeah, this was an expensive issue to work out too.. turned out I had 3 drives with bad sectors, and whenever there was data being read/written on those sectors the server would crap out... unfortunately they weren't reporting the issue, or at least, not via the alerting methods I'd configured... I went through and looked at the status and there was just these 3 with crc errors, removed from array, ran for a while all good, so I replaced those drives, all became sweet... it may be only 1/3 was stuck, but I replaced them all anyway, not worth the risk...

For anybody else looking up similar questions some 3+ years later ... The very helpful "archived notification menu" can be found from: webui > tools > archived notifications You can then click on a notification, and it will give you further details, as per extrobe's "NOK" paste.. (Thanks for the pointers, resolved my issue, also ended up being a hot disk )

Cool cool, makes sense. I record both, I’ll just keep the purchased date in your app and just keep my secondary spreadsheet for the extra details many thanks!!

Hiya @olehj, first off, many thank for this great plugin!!! I've a question for you, how difficult/feasible would it be to add an extra manual column? Specifically, I'd like to have a "Manufactured Date". I realise this info could be adden in the comments area, but that begins to look untidy quickly. Cheers

So I did the `killall lsof` about an hour ago, and it's just started a dozen or so instances of the previous mentioned 'lsof' command, and all cpu cores are at 100% .. I failed to mention before, that the whole system is lagging when this happens, even ICMP calls to it the latency will go up by 5-20 seconds.. due to CPU wait time.

Hi one and all, for the past few weeks I've been having some weird CPU issues, I would see my docker images og to 80-160%, and a whole heap of "lsof" tasks would start being created. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3035 201 39 19 186904 154500 0 S 104.6 0.5 276:22.82 netdata 9886 nobody 20 0 1745432 424548 19832 S 100.3 1.3 176:57.72 mono 8705 nobody 20 0 4245124 506380 19328 S 97.0 1.5 567:37.83 Radarr 29112 root 20 0 1142100 92976 1136 S 78.3 0.3 218:40.05 shfs 23106 root 20 0 118948 12160 4768 R 59.2 0.0 0:11.66 runc 23159 root 20 0 188844 9564 4768 R 58.6 0.0 0:10.05 runc 23700 root 20 0 188780 11592 4704 R 51.3 0.0 0:02.11 runc 6192 root 20 0 2572 92 0 R 42.4 0.0 4:09.84 lsof 11290 root 20 0 3036 2032 1788 R 42.1 0.0 2:52.91 lsof 13951 root 20 0 3036 2008 1764 R 41.8 0.0 2:10.79 lsof 1186 root 20 0 3036 1992 1748 R 41.1 0.0 5:40.82 lsof 5954 root 20 0 3036 2032 1788 R 41.1 0.0 4:29.93 lsof 17990 root 20 0 3036 1992 1748 R 41.1 0.0 1:17.00 lsof 22466 root 20 0 3036 2020 1772 R 40.8 0.0 0:14.81 lsof 14587 root 20 0 3036 2104 1860 R 40.5 0.0 2:06.38 lsof 4547 root 20 0 3036 1920 1664 R 39.8 0.0 4:48.70 lsof 8947 root 20 0 3036 2044 1804 R 39.8 0.0 3:36.63 lsof 16682 root 20 0 3036 1944 1692 R 39.8 0.0 1:32.10 lsof 17283 root 20 0 3036 2088 1844 R 39.5 0.0 1:24.76 lsof 21801 root 20 0 3036 2008 1764 R 39.5 0.0 0:22.42 lsof 18524 root 20 0 3036 2008 1764 R 39.1 0.0 1:10.05 lsof 23589 root 20 0 12488 10748 2068 R 39.1 0.0 0:02.45 find 19585 root 20 0 3036 1936 1684 R 38.8 0.0 0:46.96 lsof 8086 root 20 0 3036 1932 1684 R 38.5 0.0 3:45.83 lsof 12631 root 20 0 3036 2028 1788 R 38.5 0.0 2:34.27 lsof 13322 root 20 0 3036 1988 1748 R 38.2 0.0 2:23.64 lsof 3817 root 20 0 3036 2008 1764 R 37.2 0.0 5:01.57 lsof 18737 root 20 0 3036 2020 1772 R 37.2 0.0 1:02.63 lsof 21037 root 20 0 3036 2048 1804 R 35.9 0.0 0:28.03 lsof 11991 root 20 0 3036 1988 1748 R 35.5 0.0 2:44.38 lsof 2731 root 20 0 3036 2100 1860 R 34.5 0.0 5:15.58 lsof 23379 root 20 0 3036 2096 1860 R 28.9 0.0 0:03.30 lsof 530 root 20 0 1712768 1.1g 22432 S 8.6 3.6 179:43.71 qemu-system-x86 1968 root 20 0 21.0g 815380 20404 R 6.9 2.5 35:21.06 influxd 1027 root 20 0 1691316 1.2g 22204 S 6.6 3.7 58:46.69 qemu-system-x86 23179 nobody 20 0 4312 3276 1768 R 4.9 0.0 0:00.83 unrar 10366 root 20 0 842064 92836 6196 S 3.6 0.3 672:58.29 telegraf 23750 root 20 0 16656 4540 3652 R 2.0 0.0 0:00.06 snmpget At first I thought it was the docker images/disk that was the issue, but I learnt today that it is far more likely to be these lsof tasks as the cause, and that the docker cpu utilisation is a symptoms. All of the lsof images look the same: root 11289 0.0 0.0 3840 2916 ? S 14:15 0:00 sh -c LANG='en_US.UTF8' lsof -Owl /mnt/disk[0-9]* 2>/dev/null|awk '/^shfs/ && $0!~/\.AppleD(B|ouble)/ && $5=="REG"'|awk -F/ '{print $4}' root 11290 48.7 0.0 3036 2032 ? R 14:15 3:08 lsof -Owl /mnt/disk1 /mnt/disk10 /mnt/disk11 /mnt/disk12 /mnt/disk13 /mnt/disk14 /mnt/disk15 /mnt/disk2 /mnt/disk3 /mnt/disk4 /mnt/disk5 /mnt/disk6 /mnt/disk7 /mnt/disk8 /mnt/disk9 I've grepped through various folders that I thought might have something and the only thing I can find that was close was, the plugin file for dynamix' stop shell: # find /boot/config/plugins -type f -exec grep -H lsof {} \; /boot/config/plugins/dynamix.stop.shell.plg:for PID in $(lsof /mnt/disk[0-9]* $cache /mnt/user /mnt/user0 2>/dev/null|awk '/^(bash|sh|mc) /{print $2}'); do I have nothing in crontab that's even slightly close, and no other scripts set to run that are at all similar in user.scripts etc.. perfoming a `killall lsof` will make it good for a short while, but there is still something performing an lsof on unassigned drives. I also had one Google search, whcih looked promising, and led me to here but then I couldn't find the text within the actual page. I did have a CPU issue a while back due to ryzen cpu, but that has (presumably) been resolved for a while now .. I can post diagnostics if needed, but if anybody has suggestions, I'd highly appreciate it!!!

@paperblankets I got mine solved, hopefully you can too. I installed a second docker, which worked fine, then had a look at the file structure, the permissions were very different, one by one I chmod'd every single file and directory in /var/log for poste's docker. I now get no errors at all, even after reboot. Running Version 2.2.21 Free. Hope it helps.

A very short time after this, I rebooted the container, and ran the logrotate again. This time I got a bunch of errors for items in /var/log: " because parent directory has insecure permissions (It's world writable or writable by group which is not "root") Set "su" directive in config file to tell logrotate which user/group should be used for rotation. I changed permissions on those folders to 755, and chowned to root, and it all started working, no errors. On reboot though, it reclaims the folders and errors come back. I tried rolling the docker back 2 months, and then 2 years, but same issue. Might look at editing the "su" config for it.

Can't tell you why, but I'm having the exact some issue... exact same number and everything. It's working fine, just get that email every day for the past while. root@mail:/etc/cron.daily# logrotate /etc/logrotate.conf pkill: cannot allocate 4611686018427387903 bytes

Well, uptime is now 49 Hours, I'm going to go ahead and close this off as solved. Thank you very much @johnnie.black for your help and pointing me to the solution!!! TL;DR dropped ram speed from 3200MHz to (auto) 2133MHz solved the issue.

So far so good, uptime 21 hours 47 minutes since the ram speed change. Being that I'd previously had the same C-State settings, I doubt that will have made a difference, but who knows?! Will keep monitoring

Purely out of interest, setting the memory to defaults, changed the speed to 2133 MHz.

Thanks @johnnie.black I note two things from that: First that my alleged max supported memory speed for 2nd gen is not 3200 as per what the motherboard says (and what I've configured), I'll lower this and see how that goes. Second, I also note from the link in that thread that I shouldn't be turning of c-states, and instead leave it to auto. I'll do that as well.. Will let you know how I get on tomorrow

Of note, one other thing I did was to disable C-States, in case the NVME drive was somehow going to sleep, I haven't undone this change.

Seconded, I'd love to see this feature.