3 hours ago, yonesmit said:

Are you running unraid 6.12.x ?

In both rc.0 and rc.6 i find:

# Unmount local file systems:
echo "Unmounting local file systems:"
/bin/umount -v -a

may be this is a new addition in 6.12 (because as I said the UPS power off was working ok with my ups when I tested time ago).

And also UPS shutdown when i run from command line:

upsdrvctl -u root shutdown

 

I looked my plugins and I don't find anyone adding the "umount -v -a" command so it must be from unraid 6.12

 

Please, can anyone running unraid 6.12.x confirm if "/bin/umount -v -a" is present in file /etc/rc.d/rc.6 or not?

 

Thnaks in advance

 

 

 

If this line really is there in all versions 6.12.x this must've been an addition in a newer than mine UNRAID version and you might be right about your observation that the plugin is attempting to call a binary which is no longer there due to previous mass-unmounting of all filesystems including the root filesystem. I'm unfortunately running an older version of UNRAID myself so I can't really investigate much more into that direction, in my version the root filesystem does not get unmounted as part of the shutdown.

 

This new way of mass-unmounting all filesystems poses a more complex problem to killing the UPS power however. We cannot simply move the NUT kill-power command to above the mass-unmount command, because then theoretically the UPS would be able to kill the power in the middle of unmounting some more critical filesystems... resulting in an unpredictable end result of the actual shutdown - you'd never know if it was a 100% clean shutdown. The reason is that the UPS doesn't know and won't wait for what's going on, it only gets the command to kill the power to the devices pronto.

 

In my eyes the only possibility to mitigate that risk would be re-mounting the necessary root filesystem as read-only after the mass-unmounts are already done, so that the necessary binary becomes available to the shutdown script once again before the system halts - but this way making sure all critical filesystems were successfully unmounted before.

 

Judging by my rc.6 file this has actually been done in older versions of UNRAID and that functionality was later commented out and deactivated because the root filesystem wasn't unmounted (anymore) due to being in RAM anyway (until now apparently).

 

But generally adding such a remount as part of a plugin would be, at least in my opinion, a major and particularly an unpredictable change of the system's base shutdown sequence. Personally I'm out of my depth here at the moment as I wouldn't know how such a change would effect all other (older) versions of UNRAID.

 

P.S. I'll test this with a newer version and report back here on my findings.

Edited July 22, 20232 yr by Rysz

2 hours ago, xsweb said:

Unfortunately no (Version 2023.07.22). Up to 60W or 10% power it shows the correct consumption, above 60W respectively 11% power, it shows only "1W" as the current consuming in the status bar.

Maybe the error can be found quickly, otherwise it doesn't really bother.

can you prove the output of upsc ups@localhost or @IP address?

17 minutes ago, SimonF said:

can you prove the output of upsc ups@localhost or @IP address?

 

I think nut reports wrong value from the UPS.

In the screen cap from his post ups.power.nominal=5 with a 1200VA UPS (PowerWalker VI 1200 SHL), should be 1200. Same for ups.realpower=0 with load at 10%.

 

In general in this plugin, maybe I'm wrong, there are some mistakes in display of values for the power. Mixes of apparent power (VA) and real/true power (W), apparent power displayed in Watt and not in VA.

16 minutes ago, Peuuuur Noel said:

 

I think nut reports wrong value from the UPS.

In the screen cap from his post ups.power.nominal=5 with a 1200VA UPS (PowerWalker VI 1200 SHL), should be 1200. Same for ups.realpower=0 with load at 10%.

 

In general in this plugin, maybe I'm wrong, there are some mistakes in display of values for the power. Mixes of apparent power (VA) and real/true power (W), apparent power displayed in Watt and not in VA.

This is the code used. I suspect issue is that realpower exists but has incorrect value.

 

  $wattage = round($power*$load*0.01)."w";
  if ($power && $load) $status[1] = "<span id='".($config['FOOTER_STYLE'] == 1 ? "copyright" : "nut_power")."' class='tooltip-nut ".($load>=90 ? "$red" : ($config['FOOTER_STYLE'] == 1 ? "$black" : "$green"))."' data='{$nut_name}: consuming $wattage ($load% of capacity)'><i class='fa fa-plug'></i>&thinsp;$wattage</span>";
  if ($realpower != NULL && $load) {$realpower=$realpower.'w' ; $status[1] = "<span id='nut_power' class='tooltip-nut ".($load>=90 ? "$red" : ($config['FOOTER_STYLE'] == 1 ? "$black" : "$green"))."' data='{$nut_name}: consuming $realpower ($load% of capacity) Calculated Wattage: $wattage'><i class='fa fa-plug'></i>&thinsp;$realpower</span>"; }

 

@SimonF yes, ups.realpower has a wrong value.

If @xsweb can do an usbhid-ups for a minute it should help to check if raw value for this UPS is reliable or not.

Edited July 22, 20232 yr by Peuuuur Noel

@SimonF I made some changes in code for better calculation and display in settings/footer/dashboard between apparent power and real power, depending of what NUT retrieves from the UPS.

Feel free to review it.

https://github.com/SimonFair/NUT-unRAID/pull/4

46 minutes ago, Peuuuur Noel said:

@SimonF I made some changes in code for better calculation and display in settings/footer/dashboard between apparent power and real power, depending of what NUT retrieves from the UPS.

Feel free to review it.

https://github.com/SimonFair/NUT-unRAID/pull/4

Thankyou for the PR, I will review.

22 hours ago, Rysz said:

 

If this line really is there in all versions 6.12.x this must've been an addition in a newer than mine UNRAID version and you might be right about your observation that the plugin is attempting to call a binary which is no longer there due to previous mass-unmounting of all filesystems including the root filesystem. I'm unfortunately running an older version of UNRAID myself so I can't really investigate much more into that direction, in my version the root filesystem does not get unmounted as part of the shutdown.

 

This new way of mass-unmounting all filesystems poses a more complex problem to killing the UPS power however. We cannot simply move the NUT kill-power command to above the mass-unmount command, because then theoretically the UPS would be able to kill the power in the middle of unmounting some more critical filesystems... resulting in an unpredictable end result of the actual shutdown - you'd never know if it was a 100% clean shutdown. The reason is that the UPS doesn't know and won't wait for what's going on, it only gets the command to kill the power to the devices pronto.

 

In my eyes the only possibility to mitigate that risk would be re-mounting the necessary root filesystem as read-only after the mass-unmounts are already done, so that the necessary binary becomes available to the shutdown script once again before the system halts - but this way making sure all critical filesystems were successfully unmounted before.

 

Judging by my rc.6 file this has actually been done in older versions of UNRAID and that functionality was later commented out and deactivated because the root filesystem wasn't unmounted (anymore) due to being in RAM anyway (until now apparently).

 

But generally adding such a remount as part of a plugin would be, at least in my opinion, a major and particularly an unpredictable change of the system's base shutdown sequence. Personally I'm out of my depth here at the moment as I wouldn't know how such a change would effect all other (older) versions of UNRAID.

 

P.S. I'll test this with a newer version and report back here on my findings.

As a temporary solution I will make a script to copy usbhid-ups binary (my ups driver) to /etc/nut and then patch /etc/rc.d/rc.nut to stop calling "upsdrvctl shutdown" and call to this binary directly to shutdown ups. Unfortunately the shutdown command is different for every UPS (depending on driver used and UPS manufacturer) so this should be only a temp solution.

 

It's strange nobody has complained about this... and nobody using 6.12.x confirmed if his rc.6 contains or not the line:

/bin/umount -v -a

 

Best Regards,

 

 

 

 

On 7/21/2023 at 9:47 PM, yonesmit said:

 

It's very strange because in unraid shutdown script (rc.6) you can find this command:

/bin/umount -v -a

the output of this command in my system is:

/mnt                     : successfully unmounted
/sys/fs/cgroup           : successfully unmounted
/hugetlbfs               : successfully unmounted
/sys/fs/fuse/connections : successfully unmounted
/dev/shm                 : successfully unmounted
/dev/pts                 : ignored
/usr                     : successfully unmounted
/usr                     : successfully unmounted
/lib                     : successfully unmounted
/lib                     : successfully unmounted
/run                     : successfully unmounted
/sys                     : ignored
/proc                    : ignored

so /usr is unmounted.

it is imposible that later UPS can be shutdown:

/usr/sbin/upsdrvctl shutdown

 

I think that this command should be run before unmounting the drive.

How can you ups shutdown?

 

Best Regards,

 

 

 

Just to check back here, I've tested this with 6.12.3 and you're right about your observations. I actually consider this unwanted behaviour and something UNRAID should fix as it's likely causing problems for the system and other plugins as well. Hacking together a plugin-wise solution for this does not seem practical and would require re-mounting parts of the unmounted filesystems, something that I think no plugin should do lightly and without a very good reason.

 

I've submitted a relevant bug report in hopes of getting this fixed in newer versions of UNRAID.

 

19 hours ago, Peuuuur Noel said:

@SimonF I made some changes in code for better calculation and display in settings/footer/dashboard between apparent power and real power, depending of what NUT retrieves from the UPS.

Feel free to review it.

https://github.com/SimonFair/NUT-unRAID/pull/4

Merged and released in 2023.07.23

 

I have merged @Peuuuur Noel changes into my plugins. If your are running 2.8 you need to load the plugin via https://raw.githubusercontent.com/SimonFair/NUT-unRAID/master/plugin/nut-2.8.0.plg

 

Thanks for the PR.

@SimonF

looks like v2023.07.23 destroid the "newer" footer style.

Edited July 23, 20232 yr by sonic6

9 minutes ago, sonic6 said:

@SimonF

looks like v2023.07.23 destroid the "newer" footer style.

Is that for small version?

Just now, SimonF said:

Is that for small version?

sorry missed that information, yes.

4 hours ago, Rysz said:

 

Just to check back here, I've tested this with 6.12.3 and you're right about your observations. I actually consider this unwanted behaviour and something UNRAID should fix as it's likely causing problems for the system and other plugins as well. Hacking together a plugin-wise solution for this does not seem practical and would require re-mounting parts of the unmounted filesystems, something that I think no plugin should do lightly and without a very good reason.

 

I've submitted a relevant bug report in hopes of getting this fixed in newer versions of UNRAID.

 

I have notified this to Limetech.

30 minutes ago, SimonF said:

https://raw.githubusercontent.com/SimonFair/NUT-unRAID/master/plugin/nut-2.8.0.plg

 

it cant be updated by auto update? 

v2.8.0 on 2023.02.14 version was autoupdated  to 2023.06.03 v 2.70 somehow ...

1 minute ago, Masterwishx said:

 

it cant be updated by auto update? 

v2.8.0 on 2023.02.14 version was autoupdated  to 2023.06.03 v 2.70 somehow ...

I think this is the reason

<!ENTITY pluginURL "&gitURL;/plugin/&name;.plg">

should be

<!ENTITY pluginURL "&gitURL;/plugin/&name;-2.8.0.plg">

inside nut-2.8.0.plg

1 minute ago, Rysz said:

inside nut-2.8.0.plg

 

Also, manual plugin update cant find new update

3 minutes ago, Rysz said:

inside nut-2.8.0.plg

can you please make PR for it ?

9 minutes ago, Rysz said:

I think this is the reason

<!ENTITY pluginURL "&gitURL;/plugin/&name;.plg">

 

Thanks it Fixed for manual update

1 hour ago, sonic6 said:

sorry missed that information, yes.

Thanks will be fixed in the Release 2023.07.23a.

5 hours ago, Rysz said:

 

Just to check back here, I've tested this with 6.12.3 and you're right about your observations. I actually consider this unwanted behaviour and something UNRAID should fix as it's likely causing problems for the system and other plugins as well. Hacking together a plugin-wise solution for this does not seem practical and would require re-mounting parts of the unmounted filesystems, something that I think no plugin should do lightly and without a very good reason.

 

I've submitted a relevant bug report in hopes of getting this fixed in newer versions of UNRAID.

 

Thanks a lot for testing and also for reporting it as a bug. I also think this is a bug, /usr and /lib should not be unmounted! Remounting it imply to reinstall the plugins!! 

Temporarily I use this script to shutdown my UPS:

#!/bin/bash

FILE_TO_PATCH="/etc/rc.d/rc.nut"
CMD_TO_COMMENT="/usr/sbin/upsdrvctl shutdown"
CMD_TO_ADD="/root/usbhid-ups -u root -s ups -x port=auto -x offdelay=20 -x ondelay=30 -k"

cp /usr/libexec/nut/usbhid-ups /root/usbhid-ups
chmod 755 /root/usbhid-ups
if grep -q "$CMD_TO_ADD" $FILE_TO_PATCH; then
  echo "file $FILE_TO_PATCH already patched"
else
  sed -i "s|\(^.*\)\($CMD_TO_COMMENT\)|\1#\2\n\1$CMD_TO_ADD|" $FILE_TO_PATCH
  echo "patching $FILE_TO_PATCH done"
fi  

CMD_TO_ADD is for my UPS and need to be correctly setup for others. Also if UPS uses other driver then the correct driver should be used.

 

I hope they "fix" the issue soon.

 

Best Regards

 

55 minutes ago, Masterwishx said:

can you please make PR for it ?

Already fixed.

12 hours ago, SimonF said:

Thanks will be fixed in the Release 2023.07.23a.

sadly it is still present in 2023.07.23a

Hi,
The update to separate apparent power and real in 2023.07.23a is great, however if the UPS capacity is manually adjusted under display settings the footer shows incorrect real power (the value on the dashboard and on the settings page is correct)

 

Example with a UPS that uses the default values:

 

Setting the capacity to "auto" the values are identical:

 

I hope this can be looked at,

Thanks

@thecode I don't have that issue over here with Manual:

 

If I change that back to Auto it looks like that:

 

You might have to wait a bit until the Footer/Plugin page updates the values depending what refresh interval you've set.