Alt-F and UPS

[Francesco Lumachi]

Do you plan to implement any UPS functionality like clean shutdown in the event of a power outage?
Thank you for the awesome work!!

[João Cardoso]

On Sunday, 24 January 2016 15:09:07 UTC, Francesco Lumachi wrote:

Do you plan to implement any UPS functionality like clean shutdown in the event of a power outage?

The Alt-F package "Network UPS ToolS"  (nuts :-) already does that, but you must set it up manually. A generic webUI should not be easy as there are many UPS brands/models and each one has its own interface and characteristics (although some claim NUT compatibility).

Search the forum, someone (not me) has already used the Alt-F package.

[Konstantin Slipenko]

I have configured NUT to work with my UPS. The problem is that after the reboot, the DNS325 does not see the connected UPS. LSUSB does not display connected UPS. You need to pull out the cable and reconnect.

What can be done in this case?

воскресенье, 24 января 2016 г. в 22:23:35 UTC+3, João Cardoso:

[João Cardoso]

On Monday, February 15, 2021 at 7:07:25 AM UTC Konstantin Slipenko wrote:

I have configured NUT to work with my UPS. The problem is that after the reboot, the DNS325 does not see the connected UPS. LSUSB does not display connected UPS. You need to pull out the cable and reconnect.

What can be done in this case?

Probably a specific kernel module needs to be loaded. See with 'lsmod' if a new kernel module is loaded when repluging.

Are you using or have modified '/etc/init.d/S22nut' (with a 'rcnut' command alias). It might need to be modified to load the kernel module. Alternatively you can specify it in '/etc/modules'

[Konstantin Slipenko]

This is what I see in dmsg immediately after loading
...
usb 1-1: new low-speed USB device number 3 using orion-ehci
hid-generic 0003:0665:5161.0001: device has no listeners, quitting
...
usbcore: registered new interface driver usblp

And no devices in /dev/bus/usb

# lsmod
Module                  Size  Used by    Not tainted
usblp                   8480  0
ipv6                  247420 20 [permanent]

Now I reconnect the UPS

usb 1-1: USB disconnect, device number 3
usb 1-1: new low-speed USB device number 4 using orion-ehci
hid-generic 0003:0665:5161.0002: device has no listeners, quitting

# lsmod
Module                  Size  Used by    Not tainted
usblp                   8480  0
ipv6                  247420 20 [permanent]

Now the device /dev/bus/usb/001/??? is there and NUT can work normally

What else can I check? Thank.

понедельник, 15 февраля 2021 г. в 21:35:35 UTC+3, João Cardoso:

[João Cardoso]

On Tuesday, February 16, 2021 at 10:21:48 AM UTC Konstantin Slipenko wrote:

This is what I see in dmsg immediately after loading
...
usb 1-1: new low-speed USB device number 3 using orion-ehci
hid-generic 0003:0665:5161.0001: device has no listeners, quitting
...
usbcore: registered new interface driver usblp

And no devices in /dev/bus/usb

# lsmod
Module                  Size  Used by    Not tainted
usblp                   8480  0
ipv6                  247420 20 [permanent]

Now I reconnect the UPS

usb 1-1: USB disconnect, device number 3
usb 1-1: new low-speed USB device number 4 using orion-ehci
hid-generic 0003:0665:5161.0002: device has no listeners, quitting

# lsmod
Module                  Size  Used by    Not tainted
usblp                   8480  0
ipv6                  247420 20 [permanent]

Now the device /dev/bus/usb/001/??? is there and NUT can work normally

What else can I check? Thank.

There is an old thread about NUT issues, "UPS tools / usbfs error", see https://groups.google.com/g/alt-f/c/Wtc6geFyypk/m/FrbUTwp0DxcJ

That is pretty old and seems (I just glimpsed though it) to be related to issues when plugging, which is not your problem. You problem seems to be related to kernel compilation, "some say" that it must be compiled with HIDRAW set (HIDDEV is already set), "others say" that USB_EHCI_TT_NEWSCHED must be set (this writing is mostly for my own future reference).

So, I can't try... (and I'm using another kernel anyway). Perhaps one could send/emulate a hotplug event? Even though /dev/usb/... does not exists(1), perhaps /sys/bus/usb/drivers/usb/... exists, and one could send an unbind/bind(2) event to it (mostly an 'echo add > /sys/bus/.../uevent')

1) hotpluging and device node creation is handled by 'mdev', configure through /etc/mdev.conf and /usr/sbin/hot.sh, producing a log at /var/log/hot.log.

(2) The classic solution is to unload the kernel module and reload it, but that can't be done as it is builtin.

 

You might identify the usb device in the /sys/bus/usb/... when it works, and see if it exists after rebooting; if yes, do the 'echo add'

Do you feel comfortable at this level? I'm afraid I can't help further without experimenting myself. Please keep us informed of your progresses.

[Bill Rosenberg]

Hi João, back in 2018 you stepped me through creating my own 323 firmware build so I could run apcupsd with a USB UPS. I looked back at our SourceForge conversation and I was able to get it to work and fit the flash space by building with CONFIG_HID_GENERIC=y, CONFIG_USB_HIDDEV=y, HMAC=m, CRYPTO_ANSI_CPRNG=m. I would think that if this works with apcupsd it will work with nut too.

[Konstantin Slipenko]

I have compiled a firmware with HIDDEV and HIDRAV support, but that did not solve the problem.

I have compiled the firmware with hid-generic as a module. Unloading and loading of the hid-generic module does not create devices in /dev/ bus/ usb.

The problem was solved simply by writing to /sys/bus/usb/devices/usb1/1-1/uevent

Here is the code I added to rc.sys

if [ -f /sys/bus/usb/devices/usb1/1-1/uevent ]; then

  echo "add" > /sys/bus/usb/devices/usb1/1-1/uevent

fi

For NUT to work correctly, I had to add the UPS user to the ROOT group.

In the startup script for NUT, access rights to /etc/nut are incorrectly set.

Also, in the NUT startup script, the UPSMON and UPSD programs cannot be stopped due to an error with saving PID processes.

I made a patch to fix these problems.

Thanks to colleagues for the quick replies in this discussion. I'm sorry for my bad English.

среда, 17 февраля 2021 г. в 03:38:13 UTC+3, Bill Rosenberg:

[João Cardoso]

On Wednesday, February 17, 2021 at 4:07:16 PM UTC Konstantin Slipenko wrote:

I have compiled a firmware with HIDDEV and HIDRAV support, but that did not solve the problem.

Have you tried to set USB_EHCI_TT_NEWSCHED also? "Some say" it will solve similar problems.

I have compiled the firmware with hid-generic as a module. Unloading and loading of the hid-generic module does not create devices in /dev/ bus/ usb.

The problem was solved

Using the Alt-F kernel or your own build kernel with HIDDEV and HIDRAV? as a module or builtin?

 

simply by writing to /sys/bus/usb/devices/usb1/1-1/uevent

Here is the code I added to rc.sys

if [ -f /sys/bus/usb/devices/usb1/1-1/uevent ]; then

  echo "add" > /sys/bus/usb/devices/usb1/1-1/uevent

fi

For NUT to work correctly, I had to add the UPS user to the ROOT group.

In the startup script for NUT, access rights to /etc/nut are incorrectly set.

Also, in the NUT startup script, the UPSMON and UPSD programs cannot be stopped due to an error with saving PID processes.

I made a patch to fix these problems.

Thanks, applied to my sources.

Doesn't the status case need a similar RC_PIDFILE treatment?

 

Thanks to colleagues for the quick replies in this discussion. I'm sorry for my bad English.

Thanks for reporting back with a solution

[Konstantin Slipenko]

Positive result obtained using original Alt-F firmware v1.0

I agree that in the the startup script NUT will correctly use RC_PIDFILE=...   when checking the status too.

среда, 17 февраля 2021 г. в 20:04:32 UTC+3, João Cardoso:

[João Cardoso]

Hi Bill, glad to hear from you!

Yes, I now recollect our sourceforge conversation.

[Konstantin Slipenko]

среда, 17 февраля 2021 г. в 20:04:32 UTC+3, João Cardoso:

On Wednesday, February 17, 2021 at 4:07:16 PM UTC Konstantin Slipenko wrote:

I have compiled a firmware with HIDDEV and HIDRAV support, but that did not solve the problem.

Have you tried to set USB_EHCI_TT_NEWSCHED also? "Some say" it will solve similar problems.

I checked that building the kernel with this flag does not solve the problem. Now the easiest way is to use the standard kernel with writing to /sys/....
In my case, the UPS worked on DNS-325 through the blazer_usb driver

[Bill Rosenberg]

Konstantin, did you try compiling the kernel with hid-generic built-in not as a module? That is what I had to do to get it to work. No rc.sys change needed it all just works. I had to move some other items to modules to get the kernel to fit. That may not be an issue on the 325 but definitely was a challenge on the 323. This is what I changed in the build config:

CONFIG_HID_GENERIC=y, CONFIG_USB_HIDDEV=y, HMAC=m, CRYPTO_ANSI_CPRNG=m (last two were just to save space) 

[Konstantin Slipenko]

I've tried compiling the kernel with these options. The device /dev /hiddev0 is created at startup, but the driver blazer_usb does not work for this device.

четверг, 18 февраля 2021 г. в 03:16:22 UTC+3, Bill Rosenberg:

[Konstantin Slipenko]

For the correct operation of UPSSHED in the NUT startup script, you can make changes

SCHED_DIR=$STATE_DIR/upssched

if ! test -d $SCHED_DIR; then
   mkdir -p $SCHED_DIR
   chmod 0770 $SCHED_DIR
   chown ups:nut $SCHED_DIR
fi

...

# secure configuartion files, they contain passwords
 chown -R ups:nut $CONF_DIR
 chmod 750 $CONF_DIR
 chmod g-wx,o-rwx $CONF_DIR/*

So in CONF_DIR it will be possible to save additional shell scripts for the operation of UPSSHED

You also need to add processing of the restart parameter

...

case "$1" in
start)
...

restat)

    restart $NAME
    ;;

...

четверг, 18 февраля 2021 г. в 20:08:22 UTC+3, Konstantin Slipenko:

[João Cardoso]

Can you post/attach your working script? Thanks 

[Konstantin Slipenko]

Here's a script with the latest changes

I have a question about running scripts on system boot.

I see that all services are first stopped and then started, i.e. is RESTART

I understand that this is related to the work of MDEV, HOT.SH, HOT_AUX.SH

Is this normal behavior? The question arose because the original version of the NUT startup script did not contain RESTART processing.

Can I optimize this with some settings and exclude restarting services?

Thanks 

воскресенье, 21 февраля 2021 г. в 23:04:41 UTC+3, João Cardoso:

[João Cardoso]

On Monday, February 22, 2021 at 9:38:15 AM UTC Konstantin Slipenko wrote:

Here's a script with the latest changes

 

Thanks 

I have a question about running scripts on system boot.

I see that all services are first stopped and then started, i.e. is RESTART

I understand that this is related to the work of MDEV, HOT.SH, HOT_AUX.SH

Is this normal behavior?

 

Yes. It happens when the first Alt-F folder is found when discovering and mounting filesystems.

This is needed to start on-disk installed packages, or restart an already running service when a fw shipped package is updated on disk -- the running one must be stopped for the new one to be started.

Not all services should be restarted, however, only the ones that exists under /Alt-F/etc/init.d/, see /usr/sbin/hot_aux.sh:start_altf_dir()

Also, services whose initscript contains NEED_ALTF_DIR=1 are started, because those services need persistent storage where to maintain files or databases or whatever. They are not started at first, so NEED_ALTF_DIR means two things: don't start if Alt-F does not exists, start as soon as /Alt-F is found.

If you find some service not following the above reasoning, please report back.

 

The question arose because the original version of the NUT startup script did not contain RESTART processing.

Can I optimize this with some settings and exclude restarting services?

 

What is the use case? If plausible enough, an additional flag could be added to the "infrastructure"