>The reasoning for 'main' being the default is because NOTIFY_SOCKET is
>usually abstract (and therefore, world writable), meaning the daemon's
>children can potentially misuse the socket even if you change UIDs.
Yeah, who could possibly have thought that using a socket for this,
instead of a preopened file descriptor that the process *closes* after
notifying readiness, was a bad idea. >.>
>Unfortunately I don't see a single way of addressing this that works with
>all versions of systemd currently in use, and having seen systemd
>discussions online, I know someone will bring it up as a negative for this
>tool
Then someone will bring it up, and they'll be wrong. It won't be the
first time, and it won't be the last. Reading HackerNews is bad for your
mental health, unless you thrive on ignorance and FUD.
>Maybe the most portable way for sdnotify-wrapper to work is setting
>Type=forking and writing a PID file once we get a newline; hey, it'd be
>compatible with sysvinit too!
I'll assume you're joking here. :P
>I'd also consider shipping, or linking to, versions that rely on
>dependencies more likely to be installed on systemd machines
You can consider whatever you want, but as far as I'm concerned:
- sdnotify-wrapper is a fun tool I wrote as a PoC and put online
because
some people might like it. I don't consider it a serious project. If I
did, I would package it properly instead of having it all in a single
C file. If you want to write/maintain more serious tools that make the
s6 notification protocol compatible with $init_system_of_the_decade, be
my guest.
- more generally, I feel very strongly that running after systemd, or
any similar project, is a bad idea both technically and politically.
This means playing submissive to the other project and always being
behind in what you support. Interoperability is great, but it's better
done via coordination; when one team dictates the APIs (and uses them
as a lock-in tool) and the other one has to jump through hoops to keep
stuff compatible, this is not the spirit of free software.
Bottom line, I want to keep sdnotify-wrapper as a PoC and a starting
point for people who are interested in how the duct tape can hold at
the intersection of two ecosystems. I don't want to make it an official
project I'm committing to maintain and especially expand on.
(Hacks are fun; they cease to be fun when you become serious about them)
>My favorite part of the sd_notify protocol is the BARRIER directive. After
>exchanging fds with the server, it's essentially an ad hoc reimplementation
>of the s6 notification protocol except you don't check if it wrote anything
>back, removing the simplest form of error checking. Not even
>s6-notifywhenup was safe from Greenspun's tenth rule.
That's what happens when you try to make an interface do more than one
thing. NOTIFY_SOCKET isn't quite sure what it wants to be: is it a
channel for a readiness notification protocol, for health checking, for
fd-passing...? It doesn't have a well-specified purpose and ends up
being a generic communication mechanism between daemon and supervisor,
with an overloaded protocol, so of course specialized features added
as an afterthought will have a convoluted implementation.
(Insert red and blue button meme with a systemd dev hesitating between
"It's the official generic communication interface between systemd and
your daemon" and "it's a simple protocol you should implement yourself
instead of linking against libsystemd".)
--
Laurent
Received on Thu Jun 06 2024 - 11:54:32 CEST