sdnotify-wrapper but the other way around

sdnotify-wrapper but the other way around

[short.cross0654]

[-- Attachment #1: Type: text/plain, Size: 1001 bytes --]

Here's sdnotify-wrapper[1] but inverted: it pretends to be systemd's side of the sd-notify protocol, listens for an sd-style "READY=1", and then notifies s6 on behalf of the ready service.

There's software out there already written to work with systemd's readiness notification, and I'd like to run it under s6 without polling for readiness. In this case, I'm thinking about tailscale[2], but I wouldn't be surprised if this situation arises for other services as well.

(Ideally, of course, each service would be able to do simple s6-style readiness notification on its own. I might want to write a patch for tailscale, but I'm not sure if they'd accept it upstream.)

I've attached a rough implementation of this idea, but I'd love to know if anyone else has already done this. Or else maybe someone would find this useful as a starting point.

Emily

[1]: https://skarnet.org/software/misc/sdnotify-wrapper.c
[2]: https://github.com/tailscale/tailscale/blob/dc180916/util/systemd/systemd_linux.go

Re: sdnotify-wrapper but the other way around

[Jan Braun]

[-- Attachment #1: Type: text/plain, Size: 942 bytes --]

Hey,
short.cross0654@uwu.tube schrob:
> Here's sdnotify-wrapper[1] but inverted: it pretends to be systemd's
> side of the sd-notify protocol, listens for an sd-style "READY=1", and
> then notifies s6 on behalf of the ready service.

The cleverness of s6's readiness protocol is that it will recognize
systemd's "READY=1\n" output as an instance of its own "arbitrary bytes,
then a newline" readiness notification. So your wrapper should usually
not be necessary.
There could be programs using sd_notify to signal other things besides
readiness (notifying a "WATCHDOG=1" seems to exist), in which case such
a wrapper may indeed be needed for correct operation.
But grepping tailsacale's source indicates that they only sdnotify
readiness, thus you should get working and correct readiness status by
just setting up the notification-fd.

> I've attached a rough implementation of this idea, [...]

No attachment arrived here.

Cheers,
    Jan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re[2]: sdnotify-wrapper but the other way around

[Laurent Bercot]

>>  I've attached a rough implementation of this idea, [...]
>No attachment arrived here.

  The mailing-list manager removes *a lot* of MIME types, including
application/octet-stream, so if you're attaching a file, make sure it's
encoded as text/plain.

--
  Laurent

Re: sdnotify-wrapper but the other way around

[short.cross0654]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Sun, Mar 2, 2025, at 3:10 AM, Jan Braun wrote:
> But grepping tailsacale's source indicates that they only sdnotify
> readiness, thus you should get working and correct readiness status by
> just setting up the notification-fd.

I'm not sure how to do this, since the sd-notify protocol[1] doesn't inherit an fd; instead it looks at env var NOTIFY_SOCKET to read a path to a unix socket, which the ready service opens and uses to send datagrams. There needs to be something receiving on the other end of that socket file.

If there's a way to connect a unix datagram socket to the notification-fd provided by s6 more directly than I've done here, I'd love to know how!

> No attachment arrived here.

Attached again with a different content type.

Emily

[1]: https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html

[-- Attachment #2: sdnotifywrapper.c.txt --]
[-- Type: text/plain, Size: 1495 bytes --]

#include <stdlib.h>

#include <skalibs/allreadwrite.h>
#include <skalibs/exec.h>
#include <skalibs/socket.h>
#include <skalibs/strerr.h>
#include <skalibs/types.h>

#define USAGE "sdnotifywrapper fd socket prog..."

int newsock(char const *p)
{
    int s = ipc_datagram_coe();
    if (s == -1)
        return -1;
    if (ipc_bind_reuse(s, p) == -1)
        return -1;
    return s;
}

int monitor(int nfd, int sfd)
{
    pid_t pid = doublefork();
    if (pid != 0)
        return pid > 0 ? 0 : -1;
    size_t len = 100, n;
    ssize_t r;
    char p[len];
    for (;;) {
        memset(&p, 0, sizeof p);
        r = ipc_recv(sfd, p, len-1, NULL);
        if (r == -1)
            strerr_diefu1sys(111, "ipc_recv") ;
        char *s = p;
        while (s) {
            char *t = strsep(&s, "\n");
            if (strcmp(t, "READY=1") == 0) {
                if (allwrite(nfd, "\n", 1) == -1)
                    strerr_diefu1sys(111, "write to nfd") ;
                exit(0);
            }
        }
    }
}

int main (int argc, char const *const *argv)
{
    int nfd, sfd;
    PROG = "sdnotifywrapper" ;

    if ((argc < 4) || !uint0_scan(argv[1], (unsigned int *)&nfd))
        strerr_dieusage(100, USAGE) ;
    sfd = newsock(argv[2]);
    if (sfd == -1)
        strerr_diefu1sys(111, "create sock") ;
    if (monitor(nfd, sfd) == -1)
        strerr_diefu1sys(111, "monitor") ;
    if (setenv("NOTIFY_SOCKET", argv[2], 1) == -1)
        strerr_diefu1sys(111, "setenv") ;
    xexec(argv+3) ;
}

Re: sdnotify-wrapper but the other way around

[short.cross0654]

On Sun, Mar 2, 2025, at 3:36 AM, Laurent Bercot wrote:
>   The mailing-list manager removes *a lot* of MIME types, including
> application/octet-stream, so if you're attaching a file, make sure it's
> encoded as text/plain.

Thanks, will do!

(Since that attachment shows up on https://skarnet.org/lists/supervision/3271.html, I initially figured it must have gone through okay.)

Emily

Re: sdnotify-wrapper but the other way around

[Jan Braun]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

Hi,

short.cross0654@uwu.tube schrob:
> On Sun, Mar 2, 2025, at 3:10 AM, Jan Braun wrote:
> > just setting up the notification-fd.
> 
> I'm not sure how to do this, since the sd-notify protocol[1] doesn't
> inherit an fd; instead it looks at env var NOTIFY_SOCKET to read a
> path to a unix socket, which the ready service opens and uses to send
> datagrams.

Dang, that's what I get for not testing things; I was misremembering
that it was an inherited fd. Sorry :(

> If there's a way to connect a unix datagram socket to the
> notification-fd provided by s6 more directly than I've done here, I'd
> love to know how!

Not really. But I prefer doing things in shell when I can get away with
it, so here's a ./run script to use with ./notification-fd 3:

| #!/bin/sh
| set -eu
| 
| NOTIFY_SOCKET=`realpath ./notify`
| export NOTIFY_SOCKET
| timeout 1234 socat "unix-recvfrom:$NOTIFY_SOCKET,unlink-early" "system:paste >&3" &
| 
| # fake service:
| exec python3 -c "import systemd.daemon, time; systemd.daemon.notify('READY=1'); time.sleep(10)"

The paste(1) is there to actually create the newline. While sd_notify(3)
says "A trailing newline is implied if none is specified", python
doesn't produce one. So much for cleverly reusing that. Yay.

regards,
    Jan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: sdnotify-wrapper but the other way around

[short.cross0654]

On Mon, Mar 3, 2025, at 4:36 PM, Jan Braun wrote:
> [...] here's a ./run script to use with ./notification-fd 3:

Nice, thanks!

Emily

Re: sdnotify-wrapper but the other way around

[Jan Braun]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

Jan Braun schrob:
> | timeout 1234 socat "unix-recvfrom:$NOTIFY_SOCKET,unlink-early" "system:paste >&3" &
> [...]
> The paste(1) is there to actually create the newline.

And since by now we've strayed far from "just reuse the newline", we
might as well parse all notifications and react only to READY=1, it's no
big difference anymore:

| timeout 1234 socat \
|     "unix-recvfrom:$NOTIFY_SOCKET,unlink-early,fork" \
|     'shell:if grep -x READY=1 >&3 ; then kill $SOCAT_PPID ; fi' \
|     &

HTH,
    Jan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]