On August 18, 2021 10:25:14 PM UTC, Aaron Stewart <[email protected]> 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 <[email protected]> >Sent: Wednesday, August 18, 2021 04:39 >To: Aaron Stewart <[email protected]>; >[email protected] ><[email protected]> >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 > >[email protected] > > >________________________________ >From: Nut-upsuser ><nut-upsuser-bounces+david_zomaya=tripplite....@alioth-lists.debian.net> >on behalf of Aaron Stewart <[email protected]> >Sent: Tuesday, August 17, 2021 4:53:00 PM >To: [email protected] >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 [email protected] 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 _______________________________________________ Nut-upsuser mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
