[systemd-devel] libsystemd-daemon wrapper

[Zbigniew Jędrzejewski-Szmek]

On Wed, Mar 11, 2015 at 01:18:37PM +0100, Max wrote:
> 23.02.2015 13:29, Lennart Poettering пишет:
> > On Mon, 23.02.15 11:30, Max (maxim.suraev at campus.tu-berlin.de) wrote:
> >
> >> Hi.
> >>
> >> I've got question partially inspired by recent posts to this ML from some troll
> >> without shift on his keyboard :)
> >>
> >> It's been mentioned that calls like sd_listen_fds(0) and others become NOOP when
> >> socket activation is not available due to lack of systemd. Which is fine but leads to
> >> rather inflated code as in here: http://0pointer.de/blog/projects/socket-activation.html
> >>
> >> Is there some wrapper library which hides this boilerplate from developers?
> >>
> >> I mean instead of writing every time code like
> >>
> >> if (sd_listen_fds(0) > 1) {
> >> ... // error
> >> } else if (n == 1)
> >> ... // systemd OK
> >> else {
> >> ... // fallback to legacy
> >> }
> >>
> >>
> >> I'd really prefer to use something like:
> >>
> >> int fd = listen_on_fd_with_or_without_systemd(...);
> >>
> >> which effectively incorporates all the fallback-to-legacy logic.
> >>
> >> The same question, naturally, applies to non-scocket-activation daemons.
> >>
> >> I've tried to search for it but unfortunately came up with nothing so I'd appreciate
> >> links to such projects or to documentation which would explain why this kind of
> >> wrapper is really stupid idea :)
> > For testing purposes we do provide the "systemd-activate" tool to run
> > socket activated daemons without socket activation.
> >
> > I am not really sure thought whether we should provide more than
> > that.
> 
> I'm pretty-sure you shouldn't - I'm afraid I've been unclear. I rather though that
> such wrapper library might exist as a part of some other project which aims to
> simplify support both systemd and legacy system. Or it might have been developed
> while porting some code to systemd as an effort to try to preserve backward
> compatibility. I don't really think this belongs to systemd itself.
Internal or external to systemd is not the question.

The real problem is listed in the paragraph quoted below: the details
of opening of sockets are specific to an application, so the wrapper
library could only provide a set of helper functions which wrap BSD
socket API, but this API is already as simple as possible, so there is
nothing to be gained in doing that.

> >  The thing is simply that I cannot see how an API we would
> > provide could be any simpler than the BSD socket API is on its own. If
> > you want to listen on something, you need socket(), maybe a couple of
> > setsockopt()s, a bind() and a listen(). Any API that would wrap that
> > would kinda need the same amount of function calls, hence wouldn't be
> > any shorter or easier with it...

Zbyszek