Re: capturing system shutdown signals?

Yes, there is a daemon running that listens to the UPS. I've got some
test code in place now to try to determine what signal the kernel is
generating when the UPS tells the hardware it's shutting
down. Expensive, troublesome test though. I'm pretty sure it's a
SIGTERM (at least initially).




On Sat, 27 Apr 2024 09:25:41 -0700 (PDT)
Nathan Van Ymeren <[email protected]> wrote:

> So, Unix signals are for inter-process communication, or for kernel-process communication.
> 
> Your UPS is a separate device (I assume?) so it talks to your server over the network.  The UPS
> is most certainly sending packets that are unrelated to Unix signals.
> 
> If your server is configured to shutdown when the UPS goes on battery then there is a system
> daemon (maybe NUT [0] listening on a particular network port for comms from the UPS.
> 
> You should not have to concern yourself with the UPS; your server sounds like it's already
> shutting down properly so it's all working as intended.
> 
> Your lisp application needs to concern itself with (Unix) signals coming from the kernel.
> 
> 
> [0] https://networkupstools.org/
> 
> Apr 27, 2024 09:08:38 Jeff Cunningham <[email protected]>:
> 
> > Agree. The issue that got me most recently was a two hour power
> > interruption that eventually depleted my UPS. The UPS sends a signal
> > to shutdown the server, and I believe it is a SIGTERM. I worked
> > something up using the signal handler in the trivial-signals package
> > that works in so far as it writes the data in memory to file when a
> > SIGTERM is generated. But you are right - it's dangerous to be writing
> > a big binary file if the SIGKILL can get generated before it's
> > finished. I'll add the additional step of writing a tempfile then
> > renaming it.
> > 
> > Sounds like SIGKILL is not captured by unwind-protect but SIGTERM
> > is. Do you know if there are other signals it captures as well? I'm
> > not sure that the UPS isn't generating a SIGPWR signal rather than a
> > SIGTERM. Haven't thought of an easy way to test that yet though.
> > 
> > 
> > 
> > 
> > 
> > 
> > On Sat, 27 Apr 2024 02:36:22 +0300
> > Stas Boukarev <[email protected]> wrote:
> >   
> >> The best way to survive SIGKILL would be... not deleting the binary file
> >> until finishing writing.
> >> 
> >> 
> >> On Sat, Apr 27, 2024 at 2:00 AM Michał "phoe" Herda <[email protected]>
> >> wrote:
> >>   
> >>> On 27.04.2024 00:51, Grégory Vanuxem wrote:   
> >>>> You will first need to handle the SIGTERM, 15 , but eventually 9, hard
> >>>> kill.   
> >>> You won't need to, or even be able to, handle SIGKILL inside SBCL.
> >>> Handling SIGTERM with a clean unwind (and doing it fast enough, before
> >>> the OS follows up with SIGKILL) is probably your only good bet.
> >>>   
> > 
> > 
> > 
> > _______________________________________________
> > Sbcl-help mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/sbcl-help  



_______________________________________________
Sbcl-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-help