Hi Enrico,
There was a discussion on this list quite some time ago about the same
thing. The guts of it was yes it would be useful, but if it requires
getting upstream projects to adopt a new library we'd need to make it
compelling for them.
The most likely path would be to provide something that would provide
the interface and an optional shim that to interface with systemd
sd_notify().
However to get developer buy in, we'd probably end up having to
implement the entire systemd api in the shim and something analogous to
systemd functionality in the library to make it worthwhile instead of
using libsystemd0 directly. Not impossible but certainly looks to be a
reasonable chunk of work.
Regards,
Daniel
On 01/07/16 06:16, Enrico Weigelt, metux IT consult wrote:
> Hi folks,
>
>
> as much as I'm opposed to systemd, I see some sense in the sd_notify*()
> functions. OTOH, I dont think the API is so well thought, and I'm
> clearly opposed to having that mixed up with a lot of disjunect things
> in one big library, as systemd does.
>
> So, I'd like to propose an separate API for those service reporting
> things. That also could be coupled with a new logging API as syslog()
> replacement, which adds a bit finer granularity (eg. job-IDs, operation
> status, etc) - if that shouldn't go into its own library.
>
> The idea goes like this:
>
> * having an own library / API (in it's own .so) for service status
> notification
> * that API should provide a high level semantic API (in contrast
> to the current one, which uses pretty free-text env-type attribute
> lists)
> * we can have several implementations for it, which are binary-
> compatible (eg. build-time config).
> * it could also provide multiple in one .so (eg. autodetect which
> protocol to the service mananger to use) - as build-time config
> * distros can choose which implementations to package, maybe even
> provide multiple ones in separate packages (consumers just depend
> on a metapackage)
> * implementations then can be changed by just replacing the library
> via package manager
> * optionally, we could even have multiple ones on one system and
> use LD_PRELOAD magic to switch implementations for individual
> processes
> * service packages then should be migrated to that library and
> so breaking up the direct dependency to systemd, w/o loosing
> any functionality.
> * that library would live as it's own project, w/o any direct
> connection to systemd - in contrast to libsystemd replacement
> we dont need to keep up w/ systemd in short cycles
>
> The API could look like that:
>
>
> /** report main process pid **/
> int srvman_report_mainpid(pid_t pid, const char *msg);
>
> /** parent process report child process - eg. right after
> a fork() **/
> int srvman_report_child(pid_t pid, const char *msg);
>
> /** same as above, but a child handling a connection **/
> int srvman_report_child_fd(pid_t pid, int fd, const char *msg);
>
> /** report that the main process will be a child of the
> original one **/
> int srvman_report_mainpid(pid_t pid, const char *msg);
>
> /** report service starting **/
> int srvman_report_starting(const char *msg);
>
> /** report service ready **/
> int srvman_report_ready(const char *msg);
>
> /** report service halted **/
> int srvman_report_halted(const char *msg);
>
> /** report service waiting for resources **/
> int srvman_report_waiting(const char *msg);
>
> /** report service interrupted by some failure **/
> int srvman_report_interrupted(const char *msg);
>
> [ ... ]
>
>
> Maybe we could even extend it to allocation of resources, eg. sockets
> on privileged ports:
>
>
> /** request IP listening socket (eg. for privleged ports) **/
> /** YES: using names for addresses, so the service manager could do
> an address translation by names, eg. for dynamic IPs, etc **/
> int srvman_request_ipv4_listener(const char *localaddr,
> const char *localport,
> const char *identifier);
>
> By the way: that API, IMHO, could also be implemented on non-Unix
> platforms, eg. Windows, Plan9, ...
>
>
> What do you think about that ?
>
>
> --mtx
>
>
> --
> Enrico Weigelt,
> metux IT consulting
> +49-151-27565287
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722