Rysz

Hmm, nothing sticks out, tried reinstalling the plugin in case one of the libraries got corrupted during installation?

Yes, you can use this script in the NUT Configuration Editor in GUI: Put the commands you need inside the respective functions, in your case ONBATT_SHUTDOWN. Make sure to edit the script from within the GUI so that the changes are also saved after a reboot.

That's interesting, is this an open-source tool (the one managing your Dockers) or something self-written?

I'd recommend running an extensive RAM test since a segmentation fault occurs when a program tries to access an invalid memory address. The issue could be with Python mistakenly thinking the address is valid, or with faulty RAM corrupting previously valid memory. Since there aren’t widespread reports of this issue, my first guess would be a problem with your RAM. Unless you are running some programs in Python that are directly working on the memory (C/C++ bindings come to mind...)?

Not directly (unless uncorrectable), but ECC corrections would be displayed in the system log.

It's not possible to display multiple UPS in the GUI at the moment. It doesn't look like NUT supports your UPS from this mailing list conversation (although a bit dated): https://alioth-lists.debian.net/pipermail/nut-upsuser/2017-March/010555.html No functional changes were made to the NUT package, please try to restart NUT (or another USB port).

Thanks to everyone involved for the effort 🙂

It's possible you have the Preclear plugin installed (which includes Tmux), anyway it's not a problem - it's just an information in case something doesn't work.

I think all sides have sufficiently expressed their point of view, no need for further hostilities.

Not really, it's just a Bash script - so: https://www.gnu.org/software/bash/manual/bash.html Essentially you'll put your custom commands inside the pre-defined event functions... 🙂

You can use your own Tmux configuration, TTM doesn't interact with the configuration file any more than Tmux does. You could write a script with e.g. User Scripts that replaces the file in /etc/tmux.conf on boot, or uses sed/awk to patch it.

You can use the event hooks script with the NUT Configuration Editor in GUI:

This already should be possible, these UAMs are here: root@TowerOLD:~# ls -la /usr/lib64/netatalk/ total 192 drwxr-xr-x 2 root root 280 Feb 6 06:46 ./ drwxr-xr-x 1 root root 200 Feb 6 06:46 ../ lrwxrwxrwx 1 root root 11 Feb 6 06:46 uams_clrtxt.so -> uams_pam.so* lrwxrwxrwx 1 root root 15 Feb 6 06:46 uams_dhx.so -> uams_dhx_pam.so* lrwxrwxrwx 1 root root 16 Feb 6 06:46 uams_dhx2.so -> uams_dhx2_pam.so* -rwxr-xr-x 1 root root 27080 Nov 27 00:26 uams_dhx2_pam.so* -rwxr-xr-x 1 root root 22848 Nov 27 00:26 uams_dhx2_passwd.so* -rwxr-xr-x 1 root root 22904 Nov 27 00:26 uams_dhx_pam.so* -rwxr-xr-x 1 root root 14576 Nov 27 00:26 uams_dhx_passwd.so* -rwxr-xr-x 1 root root 22800 Nov 27 00:26 uams_gss.so* -rwxr-xr-x 1 root root 14416 Nov 27 00:26 uams_guest.so* -rwxr-xr-x 1 root root 18696 Nov 27 00:26 uams_pam.so* -rwxr-xr-x 1 root root 14496 Nov 27 00:26 uams_passwd.so* -rwxr-xr-x 1 root root 22800 Nov 27 00:26 uams_randnum.so* Add this to the [Global] section of your configuration: uam list = uams_randnum.so uams_dhx.so uams_dhx2.so passwd file = /boot/netatalk Run afppasswd to create a password file on the USB: afppasswd -c -p /boot/netatalk Add your users to that password file (these have to be names of actual Unraid users): afppasswd -p /boot/netatalk -a nobody Replace nobody with the name of actual Unraid users you want to authorize to your shares. Restart AFP service, see if it works then, I've taken the information from here: https://www.moria.us/blog/2021/03/mac-classic-hardware

Mine is the "desertwitch" one, seems the display was recently changed to the GitHub repository name. Thanks, I'll update it in the post so it's less confusing.

Eaton is by far the best supported vendor for NUT (and was a long time sponsor of the project). I use an Eaton 5P series myself and I'm extremely happy with it. 🙂 Usually you just need to look if the series, rather than the specific model, is supported. Anyway, for Eaton they all use the same HID, so most if not all are compatible one way or another.

It does seem like something on the USB-side of things has changed (in the kernel/OS), so I'm afraid at this point all you can do is keep it as it is now (running on the older server) or filter out these logs if it generally works despite the spamming (using the "Enable Rule-Based Syslog Filters" or "Redirection for NUT Service Logs" in NUT Settings). Hopefully a future kernel update (in the next OS versions) will resolve the issue. You can also play around with the different NUT backends (in NUT Settings) and see if using another NUT backend resolves the problem for you.

It's hard to trace a problem from these logs, everything seemed to work as expected (except for it actually shutting down). Interestingly, it also doesn't seem like some kind of race condition has occurred. The logic of the notification-handling shutdown script has been largely unchanged for the past 8 years and I've not had a significant number of other reports of this happening, so I'd consider it more of a random occurrence (especially as it seems to work in your later test). I'll still look some more into what could possibly lead to (?) race conditions and how to make the notification handling more resilient - thanks. 🙂 Please post the NUT Debug Package found on NUT Settings page. Most likely a change in the kernel's USB handling that affects your specific device, you can try on another USB port or with another USB cable and see if that does anything. Please also post your NUT Debug Package that can be found on NUT Settings page.

Please don't do this, jq is part of Unraid OS.

It's normal, just informative that simple garbage collection is occurring.

Yeah, the not yet fully developed part was directed at the prospective new "solutions", not un-get. 🙂

I think this topic is really getting out of hand recently, there's so much wrong information in here and it's a topic for support on the existing plugin but now mostly about 4 different prospective future half-"solutions". 🤯 What about just opening a new topic if there's a new plugin that's actually fully developed, instead of randomly throwing around links and tutorials that are either not fully developed or downright wrong and incompatible? I'm just saying this from a personal perspective, but it all just seems super misleading for novice users. 😕

Thanks for chiming in, indeed it's probably best to check out again the documentation here and play around with it some more: https://trapexit.github.io/mergerfs/. Many thanks for providing the new website and even more detailed documentation alongside the software. For what it's worth, many of our power users had great success implementing mergerFS into their storage setups on UNRAID and I've heard a lot of positive feedback. 🙂

Just for sake of completeness (for @trapexit who - I think - doesn't use Unraid). /boot being "special" (although I'm not sure that mergerFS cares for this) would usually mean the following mountpoint: /dev/sda1 /boot vfat rw,noatime,nodiratime,fmask=0177,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,flush,errors=remount-ro 0 0 But, why do you even want to pool /boot in the first place? It seems odd to use the USB flash drive, which Unraid loads the OS into RAM from, for media consumption? If it's for intermediate, fast-access (cached) files why not a ramdisk or otherwise better suited storage like SSD/NVMe?

I think it should be fine to recommend the software or even use it in your plugins, the license is very permissive in nature: https://github.com/trapexit/mergerfs/blob/latest-release/LICENSE 🙂

I think he just wants to make use of it as part of his plugins and asks it that's okay (to use the software).