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