<div dir="auto">With some APC rack SmartUPSes of early 2000's, as well as some larger Eaton devices, I remember them auto-powering on the load only after they charge "enough" (configurable in Eatons at least) to run for say 10 minutes - so they can tell the load to power off and hold it up long enough to guarantee safe shutdown if another outage happens. So those do turn on, but after an hour or so. Can this be your case?<div dir="auto"><br></div><div dir="auto">Jim </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 1, 2023, 19:00 Gennadiy Poryev via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net">nut-upsuser@alioth-lists.debian.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div>
    <p>Yes, that one. It made me thinking there might be some sidetrick
      to do an actual shutdown.return even if it is currently reported
      as not available.</p>
    <p>Yes, I know all these technicalities. Fortunately, load.off.delay
      works as expected in my case, with a granularity of a second,
      because of course I live-tested it. Determinate or not, 15 seconds
      turned out to be enough for all servers to shutdown themselves so
      by the time load is turned off, nothing is working from it. That
      is not the problem.<br>
    </p>
    <p>No, the power won't return that quick. It usually takes 3 to 4
      hours. Local specifics, so no power races in this case. Not the
      problem also.</p>
    <p>I am not newbie to the Linux world as I use Gentoo throughout,
      but I wasn't able to quickly figure out how to setup
      upsmon(+upssched?) to perform the tasks I need. The workflow I
      need seems to be marginal compared to the typical scenarios.
      Custom solution also allows me to integrate things like SMS
      notification in the process.</p>
    <p>But once again, this is not the problem.</p>
    <p>The problem is getting UPS to turn on the load as soon as power
      mains returns. Servers will start automatically. If a way to do
      this with my model is discovered, I will modify my daemon to use
      it instead of just load.off.delay'ing.</p>
    <p>So, where do I look/dig ? Or is this a dead end and I better buy
      other UPS model with an actual support?<br>
    </p>
    <p>Best regards,<br>
      <br>
      G.</p>
    <div>01.01.2023 19:25, Jim Klimov пише:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="auto">I wonder if you refer to <a href="https://nut-upsuser.alioth.debian.narkive.com/Fj636tRZ/support-of-shutdown-return-on-a-apc-back-ups-cs-500" target="_blank" rel="noreferrer">https://nut-upsuser.alioth.debian.narkive.com/Fj636tRZ/support-of-shutdown-return-on-a-apc-back-ups-cs-500</a>
        discussion from a decade ago...
        <div dir="auto"><br>
        </div>
        <div dir="auto">Essentially, with the command you tell the UPS
          to cut power in X seconds from now (some may not support it at
          all, some may have effective minimal units e.g. some CPS use
          whole 30 or 60 second chunks - so asking to go down in 59 sec
          often means immediately in fact).</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">This is a risky thing to request while the OS
          just begins a shutdown and would take indeterminate time to
          stop all services and unmount filesystems.<br>
          <br>
        </div>
        <div dir="auto">Traditionally NUT "killpower" handling was
          injected into the end of (init/rc-script driven) shutdown
          routine. While the drivers and upsd were stopped as any other
          services, another copy of the driver is spawned in the final
          seconds to tell the ups to cut power (on the primary server in
          upsmon terms).</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Often this part of code also deals with a "power
          race condition" (on all clients) - as your systems take time
          to go down, wall power may return and some UPS models may
          refuse to continue emergency power off. Power consumers should
          wait "a lot" (more time than the UPS provides normally) and
          reboot.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Nowadays systemd allows shutdown hooks for
          similar effect, other frameworks (e.g. SMF) might not. Anyhow
          these tricks may be time-limited by the framework ("we were
          asked to go down, so `killall -9` after X sec").</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Still, wondering what was "too convoluted" with
          standard upsmon? What could be done better? Note recent ML
          discussions about `upssched` use that may allow for
          finer-grained reaction (but that is tangentially related and
          may be "convoluted" indeed). </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Hope this helps,</div>
        <div dir="auto">Jim Klimov</div>
        <div dir="auto"><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Sun, Jan 1, 2023, 10:41
          Gennadiy Poryev via Nut-upsuser <<a href="mailto:nut-upsuser@alioth-lists.debian.net" target="_blank" rel="noreferrer">nut-upsuser@alioth-lists.debian.net</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all and
          happy new year!<br>
          <br>
          I have a server minifarm at home but it's Kyiv/Ukraine so wall
          power <br>
          goes on and off unexpectedly quite a few times a day. What I
          want is for <br>
          servers to gracefully start when power appears and gracefully
          shut down <br>
          when it disappears.<br>
          <br>
          To that end I've got some APC Back-UPS RS 1000, set up an
          usbhid-ups <br>
          driver and upsd. upsmon configuration turned out to be too
          convoluted so <br>
          I decided to write my own custom solution, since the protocol
          is fairly <br>
          simple.<br>
          <br>
          So the daemon I wrote connects to upsd and monitors
          input.voltage and <br>
          ups.status. BTW had to override pollinterval = 1 and pollfreq
          = 1 in <br>
          ups.conf to make input.voltage report input voltage in more or
          less <br>
          real-time instead of cached.<br>
          <br>
          The code logic is such that as soon as input.voltage goes
          below <br>
          input.transfer.low and ups.status goes from OL to OB the farm
          shutdown <br>
          is initiated and ups is issued INSTCMD load.off.delay command
          and is <br>
          smart enough to shut itself down too.<br>
          <br>
          So far this part of the project works OK -- the farm turns
          itself off <br>
          nicely and unattended.<br>
          <br>
          BUT.<br>
          <br>
          There seem to be lack of facility to do shutdown.return
          though. Still <br>
          have to to that manually each time.<br>
          <br>
          I've attached upsc/upscmd/upsrw outputs but so far haven't
          figured out a <br>
          combination that might do the trick. Provided my UPS can do
          it, of <br>
          course, but why shouldn't it?<br>
          <br>
           From what I've read in the certain discussion on this
          maillist that <br>
          occurred 12 years ago and from nut documentation I suspect the
          hope is <br>
          not lost and it is possible to somehow hack in proper
          shutdown.return<br>
          <br>
          But my expertise ends here. Should anyone help me run all the
          debug mode <br>
          magic I've read of and make good use of it, my thankfullness
          will have <br>
          no bounds.<br>
          <br>
          Best regards,<br>
          <br>
          G.<br>
          _______________________________________________<br>
          Nut-upsuser mailing list<br>
          <a href="mailto:Nut-upsuser@alioth-lists.debian.net" rel="noreferrer noreferrer" target="_blank">Nut-upsuser@alioth-lists.debian.net</a><br>
          <a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
        </blockquote>
      </div>
    </blockquote>
  </div>

_______________________________________________<br>
Nut-upsuser mailing list<br>
<a href="mailto:Nut-upsuser@alioth-lists.debian.net" target="_blank" rel="noreferrer">Nut-upsuser@alioth-lists.debian.net</a><br>
<a href="https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser" rel="noreferrer noreferrer" target="_blank">https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser</a><br>
</blockquote></div>