custom var in sd_notify

[lennart@xxxxxxxxxxxxxx (Lennart Poettering)]

On Do, 01.03.18 11:09, Umut Tezduyar Lindskog (umut at tezduyar.com) wrote:

> On Wed, Feb 28, 2018 at 7:04 PM, Lennart Poettering
> <lennart at poettering.net> wrote:
> > On Mo, 26.02.18 08:09, Mantas MikulÄ?nas (grawity at gmail.com) wrote:
> >
> >> > Daemons can choose to send additional variables. However, it is recommended
> >> > to prefix variable names not listed above with X_.
> >> > So naturally i tried
> >> >
> >> > sd_notify(0, "X_ANSWER=42")
> >> >
> >> > and apparently systemd has no problem with that, but my questions are 2
> >> > now:
> >> >
> >> > 1) What does systemd do with this information?
> >> >
> >>
> >> Nothing. The documentation just says in other words that "the init system
> >> must not reject packets with unknown variables", but doesn't say that
> >> systemd or any other init will store all of them anywhere.
> >
> > Currently we indeed ignore those unknown variables entirely. It has
> > been requested that we expose these variables on the bus somehow. I
> > think that would be an OK addition, but we need to think about the
> > lifecycle of those vars then so that the vars we collect don't grow
> > without bounds.
> 
> I believe this is what we do with STATUS: messages today. I was just
> curious if there is a rate limit around this sd_notify interface.

No, it's an AF_UNIX socket. That means we have to process the queued
datagrams in order.

Of course clients might decide to skip enqueuing messages if the
socket buffer is full (i.e. by setting O_NONBLOCK on the socket and
checking for EAGAIN), however that's purely on the client-side, PID 1
can't really do much else than process every single message, there's
no ratelimit.

Lennart

-- 
Lennart Poettering, Red Hat