[Nut-upsuser] Tripp-Lite USB "REMOTE SHUTDOWN"
Jim Klimov
jimklimov at cos.ru
Thu Aug 19 12:44:09 BST 2021
On August 18, 2021 10:25:14 PM UTC, Aaron Stewart <aaron.stewart at baymaterials.com> wrote:
>Absolutely.
>
>The issue showed up with shipping firmware but persists after I loaded
>20.0.1.118. Hardware S/N is 3104JLCPS795200451.
>
>Is there any hope for using it over SNMP with NUT instead? It has a web
>card installed, but It didn't seem like TrippLite MIBs were in NUT yet,
>or at least not in v2.7.4-8 that apt pulled in. I tested both "auto"
>and "ietf" MIB options in my config. IETF yielded some values but
>several uninterpreted/error values, too.
>
>[cid:867ffc5f-a3f9-46a8-9769-ad5369a0d4c7]
>IT & Office Manager
>
>________________________________
>
>P Please consider the environment before printing this e-mail.
>
>------------------------------------------------------------------------------------
>Disclaimer
>
>This message may contain confidential information and is intended
>only for the individual(s) or entities named above. Any review,
>retransmission, dissemination, distribution, copying or other use of
>this information by persons or entities other than the intended
>recipient is prohibited. Please notify the sender immediately by
>e-mail if you have received this e-mail by mistake and delete this
>e-mail from any and all computers it may be stored on. No liability
>is accepted for any errors or omissions in the contents of this
>message which arise as a result of e-mail transmission. If
>verification is required, please request a hard-copy version. No
>liability is accepted for any damage caused by any virus transmitted
>by this e-mail. The recipient should check this e-mail and any
>attachments for the presence of viruses.
>From: David Zomaya <David_Zomaya at tripplite.com>
>Sent: Wednesday, August 18, 2021 04:39
>To: Aaron Stewart <aaron.stewart at baymaterials.com>;
>nut-upsuser at alioth-lists.debian.net
><nut-upsuser at alioth-lists.debian.net>
>Subject: Re: Tripp-Lite USB "REMOTE SHUTDOWN"
>
>
>Warning: This email originated from outside of Straumann’s trusted
>e-mail environment. Do not click any links or open attachments unless
>you recognize the sender and have confidence the content is safe.
>
>
>Hi Aaron,
>
>I actually have one of the units from back then now and investigation
>is ongoing.
>
>I don't have a quick fix for you at this point, but can you shoot me
>your serial number and what firmware you loaded?
>
>Thank you,
>David Zomaya
>Tripp Lite
>
>david_zomaya at tripplite.com
>
>
>________________________________
>From: Nut-upsuser
><nut-upsuser-bounces+david_zomaya=tripplite.com at alioth-lists.debian.net>
>on behalf of Aaron Stewart <aaron.stewart at baymaterials.com>
>Sent: Tuesday, August 17, 2021 4:53:00 PM
>To: nut-upsuser at alioth-lists.debian.net
>Subject: [EXTERNAL] [Nut-upsuser] Tripp-Lite USB "REMOTE SHUTDOWN"
>
>This is an EXTERNAL email. Please take a moment and think before
>clicking any links or opening any attachments from this email. If
>suspicious, please forward to ishelpdesk at tripplite.com for review.
>________________________________
>Around March this year there was a thread on this mailing list
>“https://alioth-lists.debian.net/pipermail/nut-upsuser/2021-March/012332.html“.
>I appear to be running into the exact same issue, so I was hoping there
>was some resolution I could borrow wisdom from. Within seconds of
>connecting the USB cable from a ProxMox 6 server (Kernel 5.4.128) to a
>Tripp Lite SU2200RTXLCD2U , the UPS triggers “OUTPUT OFF REMOTE
>SHUTDOWN” and…cuts off output. Amazingly, this stack (NUT + server +
>USB + TrippLite UPS) worked beautifully at first, but has exhibited
>this behavior ever since I tested with “upsmon -c fsd”, and persisted
>through reboots. Was there any resolution to the prior discussion I can
>borrow from? Any flag or setting I should check on NUT? I already
>loaded the newest available firmware on the TrippLite unit. If I tail
>the upsmon log(s) when I plug the UPS in, the shutdown happens before
>the driver recognizes the device, leading me to assume like the
>previous poster this is out in the kernel/USB system somewhere. Thanks,
>Aaron
>P Please consider the environment before printing this e-mail.
>
>‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑
>Disclaimer
>
>This message may contain confidential information and is intended
>only for the individual(s) or entities named above. Any review,
>retransmission, dissemination, distribution, copying or other use of
>this information by persons or entities other than the intended
>recipient is prohibited. Please notify the sender immediately by
>e‑mail if you have received this e‑mail by mistake and delete this
>e‑mail from any and all computers it may be stored on. No liability
>is accepted for any errors or omissions in the contents of this
>message which arise as a result of e‑mail transmission. If
>verification is required, please request a hard‑copy version. No
>liability is accepted for any damage caused by any virus transmitted
>by this e‑mail. The recipient should check this e‑mail and any
>attachments for the presence of viruses.
>________________________________
>This message is for the addressee's use only. It may contain
>confidential information. If you receive this message in error, please
>delete it and notify the sender. Tripp Lite disclaims all warranties
>and liabilities, and assumes no responsibility for viruses which may
>infect an email sent to you from Tripp Lite and which damage your
>electronic systems or information. It is your responsibility to
>maintain virus detection systems to prevent damage to your electronic
>systems and information.
Back to original post, I wonder if `upsmon -c fsd` had left a file (e.g. `/tmp/killflag` or some such) that gets interpreted as an ongoing FSD when the client starts?
I think some such files could be expected to either be on a tmpfs (wiped by reboot) or cleared by startup of an earlier SYSV style service (if written under /etc) - so not sure how e.g. systemd integrations coded by distros outside of NUT handle this or not.
Beside this, I did see "issues" with a shutdown just after boot because the UPS was not charged enough after an outage and was both set to power-on ASAP and to actively post an FSD (which NUT recognized) if battery was below a certain charge level, since it could not guarantee a safe shutdown if wall-power would disappear again.
Jim
--
Typos courtesy of K-9 Mail on my Android
More information about the Nut-upsuser
mailing list