On 13.04.2017 08:00, Joachim Fahrner wrote:

> This is impossible with a binary distribution. systemd is not only an
> init system, it pervades the whole system. You can either compile
> packages with systemd libraries or without. But you have to decide that
> at compile time.

That's exactly what I'm trying to solve here by an *tiny* generic API.

Let's just take some example: libsrvmgt with funcs like that:

* srvmgt_daemonize()
  --> detach from controlling terminal, etc
* srvmgt_droppriv(...)
  --> drop root privileges (if we are still root)
  --> several versions, eg. with fetching the target uid/gid from env
* srvmgt_report_state(...)
  --> report the service state to the supervisor
  --> states could be eg.
    * SRVMGT_STATE_STARTUP     -- still within the startup phase
    * SRVMGT_STATE_READY_LOCAL -- ready for local clients only
    * SRVMGT_STATE_READY_ALL   -- ready for all clients
    * SRVMGT_STATE_BUSY        -- too busy to process new requests
    * SRVMGT_STATE_SHUTDOWN    -- shutting down, still finishing
                                      queued requests
    * SRVMGT_STATE_DEFERRED    -- temporarily can't accept new
                                      requests (eg. overload)
    * SRVMGT_STATE_WAITING     -- wait for resource (eg. printer
                                      needs paper or ink)
    * SRVMGT_STATE_OFFLINE     -- completely offline (eg. due some
                                      fatal error)

For start, we'd just write a small library, that logs to syslog,
perhaps maintains some pidfiles (maybe even a *compile-time* option
to route directly to libsystemd), then patch up packages that currently
use libsystemd to use our new one.

Actually, that lib would be so small, that it IMHO wouldn't even hurt
when upstreams adopted it w/o opt-out.

Later on, other folks can easily implement that for the service
monitors of their choice.

For binary packaging, the distro would at least provide the almost-dummy
version above, and additional ones fitting the individual service
monitors. Just as w/ many other similar cases, there would be some
virtual package 'libsrvmgt' and various real packages, and the
individual service monitors / init systems would depend on their
supported real packages.

At this point, there wouldn't be any technical reason for anybody
potterizing a package for the sake of service reporting. Packages can
just depend on that API, while nobody is bound to a specific
implementation. Thefore no need for any conflict anymore (at least
in that area).


--mtx