Nezil

Here is a further updated Transmission plugin that adds a lookup of the ISP allocated Internet IP address as well as the VPN tunnel Internet IP address (when connected), to the unRAID UI. https://dl.dropboxusercontent.com/s/7i6c08g0z37k3i1/Transmission-2.82r14243-i486-3nr.plg

In order to test that your Transmission client is really using the VPN tunnel, or to confirm that it is not, I recommend using the website http://www.ipleak.net/ which has a magnet link that will tell you the external internet IP address that your Torrent client is using. You'll probably visit the ipleak.net web page on a desktop OS rather than unRAID, so the section titled 'Your IP Address' at the top of the page is your regular ISP allocated internet IP address. As long as that IP address doesn't match the one detected by the magnet link, your data is encrypted over the VPN tunnel. Your ISP allocated IP address is also shown at the bottom right of your posts in this forum ;-)

By the way, you'll either need to reboot after putting that plugin in the correct place, or delete the two files that were changed in this version before running installplg. In other words, if you don't want to reboot, run the following commands after replacing the v1 plugin with the v2 in the link above: /etc/rc.d/rc.transmission stop rm /etc/rc.d/rc.transmission rm /usr/local/emhttp/plugins/transmission/transmission.php installplg /boot/config/plugins/Transmission-2.82r14243-i486-2nr.plg Refresh the unRAID UI and the change should be there and ready to go...

Try this one and see how you get on: https://dl.dropboxusercontent.com/s/fkpqyw9jqffojbd/Transmission-2.82r14243-i486-2nr.plg I also added an option to change the port that the Transmission Web Interface runs on. I was changing this in the settings.json file manually, but I thought that might be useful so I added it to the unRAID UI. Please let me know if you have any issues.

Well as I said in my earlier posts, I try to make my plugins as simple as possible since there is so many 'advanced' features that users might want, the plugin can start to get unwieldy and confusing. Advanced users are therefore open to making changes themselves as they see fit, either in the plugin itself, or in the configuration files. Having said that... I understand the need, and the fact that there would need to be manual intervention every time you made the change, rather than simply setting up a configuration file as needed. With that in mind, give me some time to think about how best to handle this, and I'll come back to you on it.

Actually Raidersan, the only thing that you'd have to change is the "bind-interface-device": "tun0" line in the transmission settings.json file. If you changed this to eth0 instead of tun0 then Transmission wouldn't use the vpn link any more, and you could still keep the VPN link up, it just wouldn't be doing anything. As soon as you want to have Transmission use the VPN again, stop it, change the settings.json file back to tun0 and restart. You might have to edit the settings.json file when Transmission isn't running, because it writes to the file as it shuts down and may overwrite your change!

First off, great tutorial jumperalex! I've actually been using an external 2.5 inch laptop drive connected via USB for my applications for several years now. My unRAID system has 15 3.5" drives, and that's pretty much all I can fit in my case, but there was just enough room behind the motherboard at the bottom of the case for a drive like this. I also figure that it runs cooler and draws less power than a 3.5" drive. In case anyone is interested, my method is subtly different from yours, and some of the changes might be useful to others on the forum. I'll try to talk through each one in turn: I ended up formatting my drive ReiserFS, simply because it was easy and I didn't need TRIM capabilities (this alters the mount command slightly of course). I mounted my drive in /apps in the root of the file system rather than in /mnt. I was worried that some shutdown scripts might try to unmount everything in /mnt, and I wouldn't want that to happen. I named the partition on my external drive 'Applications' and mounted using the /dev/disk/by-label/Applications path rather than the disk ID path, which is slightly more human readable. I chose to create an extremely simple plugin for mounting my drive, and put the plugin in the /boot/plugins folder rather than the conventional /boot/config/plugins location. Plugins in this location are installed before any plugins in the normal location, and some of my plugins reference my /apps drive at installation. The go script is run as the last thing once unRAID is booted after all plugins are installed. My smb-extra.conf file is slightly different. I have set up a single user account that I use for connecting to the unRAID system and browsing shares in normal use. I therefore defined the additional share as browseable and publicly readable, but only writeable for this one user. My smb-extra.conf looks like this: [Apps] path = /apps comment = Installed Applications Disk browseable = yes # Secure public = yes writeable = no write list = neil The full contents of my Extradrive-noarch-1nr.plg file are as follows: <PLUGIN> <!-- 2012-04-20 - Neil Robinson: First release The plugin mounts an additional drive outside of the array, before additional plugins are loaded. --> <!-- Install Script --> <FILE Name="/tmp/extradrive-install" Run="/bin/bash"> <INLINE> <![CDATA[ if mount | grep -q /apps; then echo "Apps drive mounted" else echo "Mounting apps drive..." if [ ! -d /apps ]; then mkdir /apps fi mount -o noatime,nodiratime -t reiserfs /dev/disk/by-label/Applications /apps 2>&1 fi echo "Done." ]]> </INLINE> </FILE> <!-- Plugin-Installed File --> <FILE Name="/var/log/plugins/extradrive"> <INLINE> <![CDATA[ The extradrive plugin mounts an additional drive outside of the array, before additional plugins are loaded. This is as an alternative to the cache drive. ]]> </INLINE> </FILE> </PLUGIN>

OK, I've updated the wiki page as you suggested. I was nervous to do this because I have feelings of inadequacy and was worried that I may have made some mistakes myself! Having said that, I agree that the state of the wiki would result in a build that probably more than 50% of users could not use. I hope my changes are appreciated by more than just you Jonathan!

Building the custom kernel In this, the last post of the series, I'm going to talk about the issues that I ran into creating the custom kernel that I needed. As I mentioned earlier, the process that I followed was the one used on the Lime Technology wiki (linked here), but I had to introduce a couple of changes in order to have a working pair of bzroot / bzimage files. To be fair to the authors of the wiki, the page does mention that it's under construction. I'm hoping here to simply state the solutions that I found, in case others find it useful. I first installed a clean Slackware OS in a Parallels virtual machine running on my MacBook Air. I used this OS to compile the custom kernel before moving it over to my unraid system. The only change that I needed to make was to switch on a couple of additional options in the menuconfig UI. After I'd made my changes, I ran through the following commands as shown on the wiki: make make modules make modules_install make install I then went ahead and built the required Realtek drivers from source and installed them as well. Initially, the modules_install command would place files in the wrong locations, and I ended up using the following two commands: sudo make -C /lib/modules/3.9.11p-unRAID/build SUBDIRS=/[path to Realtek driver source code]/r8168-8.037.00/src modules sudo make -C /lib/modules/3.9.11p-unRAID/build SUBDIRS=/[path to Realtek driver source code]/r8168-8.037.00/src/ INSTALL_MOD_DIR=kernel/drivers/net/ethernet/realtek modules_install The wiki page provides a great set of script files to automate the building of the bzroot and bzimage files, but I ran into a show-stopper issue that required a change... The script for bzroot-update is shown below: #!/bin/bash if [ ${DEBUG:=0} -gt 0 ] then set -x -v fi set -o nounset P=${0##*/} # basename of program R=${0%%$P} # dirname of program P=${P%.*} # strip off after last . character O=${P%_*} # Operand D=${P#${O}_} # Data (last param before _ character) source ${R}/bzroot-config.sh # KERNEL=3.9.11p-unRAID # RDROOT=/boot/initrd-unraid cd /usr/src/linux make modules_install install if [ ! -d ${RDROOT} ] ; then mkdir ${RDROOT}; fi cd ${RDROOT} || exit rsync -a /usr/src/linux/System.map ${RDROOT}/usr/src/linux rsync -av --delete /lib/modules/${KERNEL} ${RDROOT}/lib/modules/ find ${RDROOT}/usr/include -type f -exec rm {} \; find ${RDROOT}/usr/lib -name '*.a' -type f -exec rm {} \; find ${RDROOT}/usr/man -type f -exec rm {} \; find ${RDROOT}/usr/src/slackbuilds -type f -exec rm {} \; As you can see, there is a line in this script which re-runs the make modules_install command. Doing this removes the changes made by the Realtek installation, and I therefore ended up without the driver that I needed. The solution of course is to simply comment out this line in the script!

Custom Kernel with support for policy routing As mentioned in my previous post, a custom unRAID kernel is necessary, with added support for policy routing, if you want to be able to define a different route for the VPN interface. These policy routing options appear to be enabled by default in most up to date Linux builds, and I'm unsure why Lime Technology chose to leave these options disabled for us. The intention may be to simplify the kernel and reduce file size, but I cannot say for sure. I'm hopeful that Lime Technology may enable these options in future builds, so that a custom kernel is not necessary for this function. With that being said, a custom kernel is currently necessary, and I followed the process on the wiki (linked here) for how to do this. I did find that it was necessary to change a couple of things in the wiki process, and this was really only necessary because my system (and many other user systems) has a Realtek ethernet interface, which requires additional kernel modules to be installed. Firstly, I accept no responsibility for issues caused by using my updated kernel and image files, though I have been using them in my system for more than a month with no problems at all. My suggestion is that you modify the syslinux.cfg file (located in /boot/syslinux) to provide an additional option to select this new kernel at boot, and after you're satisfied with stability, perhaps consider changing this option to the default. As an example, my syslinux.cfg file looks like this: default /syslinux/menu.c32 menu title Lime Technology prompt 0 timeout 50 label unRAID OS Custom Kernel menu default kernel /bzimaged append initrd=/bzrootd label unRAID OS Custom Kernel (no plugins) kernel /bzimaged append initrd=/bzrootd unraidsafemode label unRAID OS Standard kernel /bzimage append initrd=/bzroot label unRAID OS Standard (no plugins) kernel /bzimage append initrd=/bzroot unraidsafemode label Memtest86+ kernel /memtest Downloads for my custom kernel and image files can be found below. These need to be placed in the root of the flash drive and called in the syslinux.cfg file discussed above. bzimaged: http://tinyurl.com/o8x2xhf bzrootd: http://tinyurl.com/k72k3a4

OpenVPN Plugin, Private Internet Access OVPN, and routing table modifications First off, apologies for taking so long to continue this thread. I have a 6 week old son, and supporting my wife with him is taking more of my free time than I anticipated. As discussed previously, I like to simplify the plugins that I'm using so that they have as few options in the unRAID UI as needed, and any advanced customisation work is done in the Terminal. With that in mind, I created my own simplified OpenVPN plugin, which also allowed me to use the latest openssl packages. As with my simplified Transmission Plugin, the only setting in the unRAID UI (other than enable / disable) is the location of the OVPN configuration file. It was my intention, having configured all of my plugins, that OpenVPN maintain a connected VPN tunnel at all times, so there is no unRAID UI button to connect the VPN at all; if the OpenVPN plugin is enabled, OpenVPN should just keep re-connecting the tunnel until the plugin is disabled. The key to having Transmission data only pass over the VPN tunnel, is to modify the routing tables of the unRAID system so that there are two routes for internet data. Having Transmission bind to the tunnel interface ensures that Transmission will only use the VPN route for it's data, while all of the other unRAID services will continue to use the normal default route. My OVPN file looks like this: #default privateinternetaccess ovpn lines client dev tun proto udp remote us-california.privateinternetaccess.com 1194 resolv-retry infinite nobind persist-key persist-tun # ca ca.crt tls-client remote-cert-tls server # auth-user-pass comp-lzo verb 1 reneg-sec 0 # Provide full paths to certificate and passwords files ca /apps/openvpn/ca.crt auth-user-pass /apps/openvpn/password.txt # Change routing behaviour script-security 3 route-delay 5 route-up "/apps/openvpn/route-up.sh" # Set location of Status Log status /tmp/openvpn/openvpn-status.log # Add code to re-connect if link drops keepalive 10 60 The key parts of this OVPN configuration file are the call to the route-up script, and the keepalive statement that handles re-connections. If you're using privateinternetaccess as your VPN provider, then the only change you'd perhaps make is which VPN server you choose to connect to. If you're using a different VPN provider, you'd probably only need to add the route-up and keepalive sections to their suggested OVPN file for the routing to work as desired. My route-up scripts looks like this, with comments added here to explain what's happening: #!/bin/sh # Checks to see if there is an IP routing table named 'vpn', create if missing if [ $(cat /etc/iproute2/rt_tables | grep vpn | wc -l) -eq 0 ]; then echo "100 vpn" >> /etc/iproute2/rt_tables fi echo "------------------------------------------------------------------" /sbin/ip route show echo "------------------------------------------------------------------" # Remove any previous routes in the 'vpn' routing table /sbin/ip rule | sed -n 's/.*\(from[ \t]*[0-9\.]*\).*vpn/\1/p' | while read RULE do echo "remove old rule: /sbin/ip rule del ${RULE}" /sbin/ip rule del ${RULE} done # Delete the default route setup when the OpenVPN tunnel was established /sbin/ip route del 128.0.0.0/1 via ${route_vpn_gateway} /sbin/ip route del 0.0.0.0/1 via ${route_vpn_gateway} # Add routes to the vpn routing table echo ip rule add from $ifconfig_local lookup vpn /sbin/ip rule add from ${ifconfig_local} lookup vpn # Add the route to direct all traffic using the the vpn routing table to the tunX interface echo ip route add default dev ${dev} table vpn /sbin/ip route add default dev ${dev} table vpn # Restart Transmission to load new tunnel local IP /etc/rc.d/rc.transmission restart exit 0 The comments in this script should be self explanatory, but what is not obvious, is that the default unRAID kernel does not support routing tables, and a custom kernel is therefore needed to address this; see my next post for details on this. My updated, simplified OpenVPN plugin can be downloaded here: http://tinyurl.com/ltendo6 My privateinternetaccess OVPN configuration file can be downloaded here: http://tinyurl.com/oloqz2f My route-up script can be downloaded here: http://tinyurl.com/ml94gh9

Transmission Plugin Transmission, by default, offers a setting to bind to a specific IP address (both IPv4 and IPv6 appear to be supported), and this can be used to bind to the IP address of the VPN tunnel (assuming the appropriate routing tables are set up). While I was researching this feature however, I discovered a patch for a very recent version of Transmission that includes a setting to bind to an interface rather than an IP address. Details of this patch can be found here: https://trac.transmissionbt.com/ticket/2313. Since the local IP address of your VPN tunnel usually changes each time your VPN tunnel is established, it would be necessary for the settings.json file to be updated every connection, as well as Transmission itself restarted for the changes to take effect. Binding to the tunnel avoids the need for any scripting like this, and is therefore a potentially simpler option. Unfortunately, there are no pre-built packages for the patched version of Transmission, and it was therefore necessary to compile an updated version from source, and create the package myself. The slackware package I made can be downloaded here: https://dl.dropboxusercontent.com/s/2g1thgkqguy218i/transmission-2.82r14243-i486-1nr.txz The package is obviously downloaded automatically by the associated plugin, which is a vastly simplified version based on the work of 'Influencer', who's plugin is still linked to in the wiki. The only setting available in the unRAID UI (other than enable / disable) is the location of the configuration directory. If this configuration directory is on the RAM disk (which it is by default, at /usr/local/transmission), the plugin will copy the settings.json file from /boot/config/plugins/transmission at boot time. Any changes made in Transmission will be lost on reboot unless they are also changed in the settings.json file on the flash drive. It is therefore suggested that the configuration directory be set to a location that persists between reboots (though not the flash disk). I personally have an additional drive running outside the array for applications, but a cache drive would also work well. As described above, I was intending to make use of the bind-interface-device support of this patched build, and therefore made the following changes to my settings.json file after installation: "bind-interface-device": "tun0", "bind-interface-enabled": true, Please note that these settings are not set by default in the plugin, because without all of the other settings that I'll be discussing in this thread also being set, Transmission would fail to download anything. My patched Transmission plugin can be found here: http://tinyurl.com/m9xcwad

I have wanted to move functions away from my ageing Mac mini OS X server onto unRAID for some time, and finally found time to get around to doing it all. One of the major features that I wanted, was to have all BitTorrent traffic routed over a OpenVPN link, disconnecting if the VPN tunnel went down, and have the rest of the unRAID server functions continue as though the VPN link were never up. If the VPN link should go down, BitTorrent traffic would simply stop, until the VPN link was restored, which it should do automatically. Initially I didn't think that this would be a complicated problem to solve, but it ended up requiring a custom Transmission build, as well as a custom Kernel build to support the routing necessary for only BitTorrent traffic to use the VPN. In this thread, I'll provide links to each of the plugins (and kernel) that I've used, and talk about any changes that I made. I'm going to be talking about: Transmission Plugin, including patched version with 'bind-interface-device' support OpenVPN Plugin, including routing table settings for Private Internet Access Custom Kernel, with support for policy routing enabled I personally like to fully understand the plugins that I'm installing, and also like to make them as transparent as possible with comments indicating what's going on. I therefore re-wrote most of the plugins I'm using here, simplifying them greatly. I'd like to point out that I didn't find anything wrong with the original plugins, but just wanted something more simple. I also need to credit the original authors of the plugins on which mine are based, and have done so in the comments at the top of each of my versions. It's no secret also, that there is a package version issue that exists with different plugins calling for different versions of the same package. I ran into issues with OpenSSL in particular, and therefore updated all of the plugins that I'm using to the latest (Heartbleed fixed) version. Updated versions of these plugins can be found in my signature below. For clarity, I've named my plugins in the standard way with a version number and my initials at the end of the filename e.g. '*-3nr.plg' for a third version.

I found the thread and post that I was looking for: http://lime-technology.com/forum/index.php?topic=15583.msg299974#msg299974 The latest version of the plugin is posted there, as well as about two pages discussing why the email notifications weren't working. Make sure to skip to my post just now about the reason why... download my example scripts rather than starting from those included with the apcupsd package (which assumes a different mail program is being used).

I posted on this a few weeks back zarfx4. I actually updated the plugin to reflect the recent bug fix in apcupsd that was affecting the newer BackUPS Pro products. I have this version set up to send emails on power events, and am using the ssmtp package included with the Dynamix Email Notify plugin in order to do this. If you don't want the Dynamix plugins, then I'm sure that all you'd need are the ssl dependencies in order to send out over an encrypted link (often required these days), and the ssmtp package itself. Configuration is easy with the Dynamix web UI, but I'm almost certain that it would be pretty straightforward without as well, since ssmtp is a very simple package for sending emails. Let me find my thread with the updated plugin and associated discussions for you...

As a last tweak... You can't move the original CrashPlan application because it will stop working. You can however 'hide' it from the OS X UI with the following Terminal command (run as sudo): chflags hidden /Applications/CrashPlan.app/ After this, you'll only have a single CrashPlan application on your mac, that only connects to unRAID, and no messing with the Terminal.

OK, so I just re-wrote the applescript application, since it was incredibly simple. The actual applescript is shown below, and obviously this just calls the script that I showed in my previous post: do shell script "/Volumes/Macintosh\\ HD\\ 2/Users/neil/Crashplan.sh" To make this look a little nicer, I called the Application Bundle 'CrashPlan unRAID', and gave it the CrashPlan icon from their application. Finally, I added the following key to the new application's Info.plist file. This key prevents the applescript application itself from having a dock icon. Because the script calls the real CrashPlan application, there would be two icons in the dock if this wasn't done. <key>LSBackgroundOnly</key> <string>1</string> I did try to attached a zip of the application, but I got a message saying that the upload folder was full. To be honest, it's probably easier to make it yourself than download it and put it in the right place anyway!

Just stumbled upon this post and thought I'd mention the method I use for connecting to the Crashplan engine running on my unRAID server. I created an extremely simple shell script in my home directory that connects the SSH tunnel, then launches the Crashplan Client Java app. When I launch the client app, I don't put it in the background, so that when I'm done checking or setting things, I close the client app, and it closes the SSH connection cleanly. ssh -N -L 4200:localhost:4243 [email protected] & /Applications/Crashplan.app/Contents/MacOS/Crashplan > /dev/null 2>&1 kill $! This does assume that you have shared key authentication set up for the SSH server in unRAID, and the relevant key on your mac as well. The SSH connection then never asks for a username or password. In the past, I did have this all set up as an Applescript application. I'll see if I can dig that out or re-write it. If I remember correctly, I renamed the original Crashplan.app in Applications .Crashplan.app so that it was hidden, and then called my Applescript application Crashplan.app in it's place. This made everything completely seamless to any user.

Scratch that... I've just taken a look at my apcupsd.conf and seen that KILLDELAY is already set at 0, so it's my UPS that is presumably 'adding' 60 seconds on to that.

I've just re-read the apcupsd documentation, and I think I was wrong about this being ignored by BackUPS units. There is no reason why I need this set at 60 seconds (the default in apcupsd.conf), so I think I'll change it and see how it behaves.

Where are you located Peter? I did a quick Google search for the BackUPS BX1100CI-MS and found that most images pointed to a product that looks like this, with what appear to be UK type plug sockets on the rear, and 240v rather than 110v: I apologise if my assumption of affected UPS models incorrectly included yours (as I think it might have). I personally have identified the problem in my (and one other replacement) BR1000G model, and I noted the issue being identified by someone with a BX1500G on the APC forum, as well as another apcupsd user on their mailing list with a BR700G unit. Perhaps it would be better to say that the fault most likely affects BRxxxG and BXxxxG units. Yours being a BXxxxCI may therefore very well not be affected. For reference, the BRxxxG and BXxxxG models all look similar to this: Possibly, but I believe the BackUPS does not take notice of the KILLDELAY setting, and this is only used for SmartUPS units. I might be wrong about this, and I didn't change the setting from default. Your model looks significantly different from mine, and the other BRxxxG / BXxxxG models, so that doesn't really surprise me at all. These newer models have a display lifted from the newer SmartUPS range, and some energy saving modes which switch off some outlets based on the current drain on others (configurable). Since these units are more complex, it stands to reason that the shutdown delay might be longer. If you would like to see a more accurate demonstration of the fault, and the timing etc. Please take a look at the videos that I made and uploaded to Box here: https://app.box.com/s/x5wmvyr0ntz4vjm8dyxr

Is this the fix you are talking about, that is, is it only necessary to build 3.14.12 and no other patches need to be applied? Yes, that is the fix that I am talking about. I have now created a 3.14.12 package using a clean Slackware 13.1 install and the SlackBuilds script. Simply updating the plugin to call for the new build would be very simple, but I'm thinking that there might be some other updates to the plugin from the testing that has been done in the x64 thread that could be incorporated at the same time. I have posted in that thread and am waiting to hear from them about the changes that have been made over the 3.14.10 plugin.

Almost Peter, but not quite... The 'bug' becomes apparent if utility power returns between the start of the connected PC shutdown (which on my unRAID system is nearly 120 seconds before the 'killpower' command is issued), and the UPS fully shutting down. The standard process for a shutdown sequence in the event of a utility power outage is something like: PC starts to shut down <- 0 seconds At the end of the PC shutdown, 'killpower' command issued <- ~120 seconds UPS waits to ensure all connected devices are really truly shut down, then kills power to protected outlets <- 60 seconds UPS goes through its own shutdown sequence, and powers off fully (presumably emptying the command buffer) <- 30 seconds This gives a window of 3 and a half minutes (~210 seconds). Although utility power being restored in this relatively short window could perhaps be considered un-likely, the result if this does happen is quite nasty - continuous un-clean shut-downs every ~60 seconds, during the boot process! The UPS is only fully shut down when the button LEDs have gone out; not simply when power is cut from the protected outlets.

Full details of the issue and fix: After a lot of testing, I discovered that my UPS (a BackUPS Pro 1000G [bR1000G]) would get stuck in a loop where after being issued a ‘killpower’ command by apcupsd, and power cycling the protected inputs, any USB enumeration (the initialisation that a USB port does in any and every OS, as well as the BIOS) would cause the ‘killpower’ command to be repeated, resulting in a potentially continuous power cycling every 60 seconds. In a real world environment, this would be every time the connected PC booted up! I noticed this bug in the first days of owning my BR1000G, and found a thread from 2010 on the APC forum where a BX1500G user had experienced the same issue. I can therefore only assume that the affected products are those from the BackUPS BRxxxxG or BXxxxxG range. During my investigation, I did receive a replacement BR1000G unit from APC, and this showed exactly the same unusual behaviour. This behaviour was consistent using apcupsd and apctest across two flavours of Linux, Mac OS X, as well as the Windows version of apctest. In fact the only version of apcupsd that resulted in correct behaviour was the Windows version of apcupsd running with the -p switch. The unique thing about the Windows implementation of apcupsd, is that Windows does not allow for the file system to be re-mounted read-only just before halting the system. The only way to power off the UPS therefore is to issue the ‘killpower’ command just before Windows starts shutting down, and hoping that the OS is shut down before the UPS shutdown sequence reaches the end of it’s timer and cuts power to its protected outlets (60 seconds when called by apcupsd / 120 seconds when called by PowerChute Personal). During Windows shutdown, the apcupsd daemon continues to run for a few seconds before it is stopped, but during this time it continues to request status information from the UPS after the ‘killpower’ signal was sent. The ‘killpower’ signal is therefore not the last command that the UPS sees before it cycles power. In all other OS situations, the ‘killpower’ command is the absolute last command sent to the UPS, just before the OS halts. All versions of apctest, including Windows, also only issue a single command to ‘killpower’ with no other commands following it, and this also results in the unusual UPS behaviour. It seems that the UPS firmware bug causes the UPS to store the last received command, and issue it again when the USB connection on the connected computer is enumerated. If this last command was the ’killpower’ command, the UPS will go through it’s shutdown and restart sequence. The UPS will actually end up stuck in this loop until one of two things happen:- - The UPS receives some other command from apcupsd or PowerChute Personal: This different command will presumably replace the ‘killpower’ command stored in the UPS, and it is this command that will presumably end up being repeated at enumeration. If the connected PC is able to boot up to the point where apcupsd starts before the UPS cycles power, the loop will be broken (although an un-clean power down will still take place). If the PC takes too long to boot up, the UPS will continue rebooting the connected PC indefinitely! - The UPS is allowed to power down completely: The only situation where this happens, is when utility power is lost long enough for the UPS to totally shut down, this is about 30 seconds after the UPS cuts power to it’s protected outlets, and is indicated by the LEDs on the UPS buttons turning off. The fix that Adam was able to implement, was to have apcupsd and apctest updated so that whenever a ‘killpower’ command is sent to the UPS, it is followed by a benign additional read data command. Presumably this benign command ends up being repeated, but doesn’t cause any problems. Like the Windows version of apcupsd (with the -p switch), PowerChute Personal probably continues to monitor the UPS after it’s issued the ‘killpower’ command to the UPS, and the firmware bug therefore never manifests itself. The bug is still present of course, but it seems that it has gone un-noticed for several years. Neil.

I've been using unRAID for several years now, and have been extremely happy with it. I moved house a few years ago however, and my utility power supply, while not exactly poor, does have a few outages each year; where I was living previously didn't have any outages at all in the three and a half years I was there. In any case, I decided that it was time to get a UPS, and decided on an APC BackUPS Pro 1000 (BR1000G). The primary reason for choosing this model was run-time. From 1000VA and upwards, the APC BackUPS units have two batteries, which equates to nearly double the run time compared to their competitors such as CyberPower. After setting up the UPS, it was time to add the apcupsd plugin; this plugin uses the apcupsd package 3.14.10. Installation went fine, but I felt that the default plugin script behaviour should be modified so that the unRAID machine did not power off when shut down. Depending on the motherboard used, it may not be possible to set the system to boot when power is supplied, but 'last state' is a very common option. By removing the references to /sbin/poweroff in the plugin script, this issue was solved for me. After I'd modified the apcupsd plugin file, I set about testing the behaviour of the UPS, and ran through a series of tests to simulate power outages and restorations at different stages of system shutdown. To cut a long story short, I discovered a bug in the firmware of the BackUPS BR (and possibly BX) series UPS products from APC, which results in the UPS getting stuck in an endless loop of un-clean shutdowns. The results of my early testing, including demonstration videos (which I sent to APC) can be found here: https://app.box.com/s/x5wmvyr0ntz4vjm8dyxr. By working with the lead developer of apcupsd, and other members of the apcupsd mailing list, we were able to track down the problem and work around it. I'll post a summary of the problem and fix in the following post to this thread, but the important thing is that the apcupsd version be updated to the latest one (3.14.12) in order to included the required patch for these UPS products. Since 3.14.12 is so new (only 1 day old), there doesn't appear to be a Slackware package prepared for it yet. I am not confident to build from source myself, and wondered if someone else would be able to do this, and then update the plugin to include this new package. Failing that, if someone could point me at some information on how I could go about creating the package myself, ideally using my unRAID installation to compile from the source code, I can have a look at doing that myself. Thanks in advance for the help! Neil.