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@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
