Guys, As a follow-on to the thread "package: network-ups-tools what happened to it?" I have discussed the fail-to-start issue with the nut developers and the reason why nut used to just "work" in the past for usb devices, but now no longer does without additional configuration. This apparently has to do with hotplug/udev permissions on newer Linux systems. I guess this went into Arch about 12-18 months ago, because that is when nut stopped working without further configuration. After working through errors starting the latest nut from git with systemd, the problem was that /dev/bus/usb/004/002 is owned by root:root forcing nut-driver.server to fail to start. Essentially upsdrvctl could not find/connect with /dev/bus/usb/004/002 and could not find the ups usb connection. Modifying the Execstart=/usr/bin/upsdrvctl start to: /usr/bin/upsdrvctl -u root start <upsname> allowed upsdrvctl to connect, but then created the state files in /var/state/ups with root:root permission which in turn caused nut-server.service (upsd) to fail on startup. upsd could not read the device files created in the state directory and could not create the upsd.pid as it was running gid "nut". Changing gid ownership of /dev/bus/usb/004/002 to root:nut solves all problem and allows upsdrvctl, upsd and upsmon to all start and connect fine. However, there is no way for the packager to know what bus a device with install or or whether it will be plugged back into the same port each time. I would like to investigate how Arch could be changed/configured so that nut simply runs out of the box as it used to before what ever changed changed. Is there a way the packager can do this? There are articles about rolling custom udev files -- that essentially accomplish linking the device to systemd and the ups name through /etc/ups/ups.conf: http://www.kepstin.ca/blog/networkupstoolsnutandsystemd/ That too is something impossible for the packager to take into account when building the package. How do we package something like nut just works after it is installed like it used to? Essentially, what is broken is nut's ability to probe and connect to the ups device on startup due to the default device permissions. Did the usb devices used to have 0666 permissions in the past? That's the only way I can see upsdrvctl being able to probe/connect to the device right out of the box. What are the security consideration of having a usb device world writable? Could we modify the default Arch udev setup to recognize UPS devices and make these world writable by default? I don't know much about the new udev/usb logic, so I'm asking, what say the experts? -- David C. Rankin, J.D.,P.E.