:: Re: [DNG] tiny service state api [W…
Pàgina inicial
Delete this message
Reply to this message
Autor: Enrico Weigelt, metux IT consult
Data:  
A: dng
Assumpte: Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
On 18.04.2017 16:08, Alessandro Selli wrote:

Hi folks,

seems that things got a bit overheated here ...

> Where did Enrico Weigelt write the monitor should get it's child PID
> from the process itself? This subthread started from these lines:
>
>>> * srvmgt_droppriv(...)
>>> --> drop root privileges (if we are still root)
>>> --> several versions, eg. with fetching the target uid/gid from env
>> Given the pid, it isn't that hard for a monitor to find the uid/gid of
>> the process, why has this have to go through the monitor ?


Perhaps I should clarify this a bit:

This library functions just shall drop privileges if the process is
still running as root - and therefore might fetch the target uid/gid
from environment (defined by start script, monitor, etc), instead of
fetching from it's own config file. It's just implementing common
repeated stuff in once central place and giving it a uniform interface.
As that library would be provided by $whatever_initsystem, any further
customizations would be done *there* instead of individual applications.

The whole thing only applies to services which *need* to be started as
root, instead of directly under the final uid/gid. (whether such things
are good design at all is a whole different discussion).

> «All daemons detach from the control terminal. The monitor and the
> daemon must coordinate each other about who's doing the detach to avoid
> launch time failures.»


ACK. That's why I would put the code that does all (on the daemon side)
into a separate library, which can be customized to whatever init/
monitor system the operator might choose, and the daemon itself doesn't
need to be touched (not even recompiled) anymore.

In that scenario, each init system (distro) package would provide an
implementation of that library - all of them share the same API/ABI,
so they can be easily replaced, w/o ever having to rebuild any daemon.

> Daemons should behave the same no matter under what monitor they are
> running under, they are not to care about this.


ACK. But there are some points where they potentially need to care
about, eg. who does the actual dataching (unfortunately, there isn't
any ultimate standard) - and I'd like to get rid of individual
per-daemon configuration (in both daemon and monitor) and delegate that
part to a library. The operator (or the init system package maintainer)
is free to put in the appropriate implementation.


--mtx