Re: capturing system shutdown signals?

It's dangerous to even handle signals. If the signal interrupts something
in the middle and you call that function again.
Or if it interrupts while holding a lock and your clean up needs that lock.

Something like this could help:

(defvar *pipe*)

(defun shutdown ()
  (declare (optimize speed))
  (sb-alien:with-alien ((x (* char)))
    (sb-posix:write *pipe* (addr x) 1))
  0)

(multiple-value-bind (read write) (sb-posix:pipe)
  (setf *pipe* write)
  (let ((stream (sb-sys:make-fd-stream read :input t
                                            :element-type '(unsigned-byte 8)
                                            :buffering :none)))
    (sb-thread:make-thread (lambda ()
                             (when (read-byte stream)
                               (write-line "Time to shutdown"))))))

(sb-sys:enable-interrupt sb-posix:sigterm
                         (lambda  (signal code context)
                           (declare (ignore signal code context))
                           (shutdown)))
(format t "~a~%" (sb-posix:getpid))

(The same could be used with named pipes, and systemd (which I'm not mixing
up, despite the claims))

On Sat, Apr 27, 2024 at 7:07 PM Jeff Cunningham <[email protected]>
wrote:

> 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