On 14.04.2017 12:06, karl@??? wrote:
> Enrico Weigelt:
> ...
>> Let's just take some example: libsrvmgt with funcs like that:
>>
>> * srvmgt_daemonize()
>> --> detach from controlling terminal, etc
>
> Why do any monitor program need to know if the program has detached
> or not, the only thing it needs to know is the pid and the state,
> which would/could be provided by the *_state() functions,
> or am I wrong ?

That function should also do the daemonizing, so it doesn't need to do
be implemented individually anymore.

BTW: I'd add pidfile handling here, so it's just done once and for all.
Reduces repeated code between individual packages and gives dists a
central hook to do whatever tweaks they might wanna do. Might also come
handy when somebody wants to have per-user services.

>> * 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 ?

As above. It's not just notifying, it's doing that. If somebody wants
an explicit notification for whatever reason (maybe just as simple as
a syslog message), he can do it there, instead of within the
individal application.

>>  --> 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)

>
> Given the choises given, it seems that the target of the monitor is
> network servers. Couldn't the monitor find out the ready_local,
> ready_all and shutdown by itself by monitoring which ports are open ?

That's not easy - the monitor would need a lot of application specific
handling. For example sendmail doesn't close the inbound socket if it
just cant accept new mails temporarily - instead it just tells that
within the smtp handshake.

My goal here is to have an simple notification for simple scenarios,
where you don't have a full-blown network monitoring (eg. nagios).
The whole thing could also be useful for per-user services that might
not even be accessible from the outside.

> What's the difference between busy and deferred, seems to be the same
> thing.

A little bit: busy means waiting for some external resource (eg.
printer ran out of paper), while deferred is due some load limit
(too high load, disk full, ...). Maybe we'd have to find better names.

> And, what if the monitor cannot trust the program it monitors ?

It's meant to be trusted (regarding security, etc) - it's just for
easier notification, so that user/operator has at least an idea what's
going on, and allows the monitor to defer startup of other depending
services, etc.

> But what if if we don't know if we can trust the walues provided by
> the program, the we have to check what the program is really doing,
> and then the lib have no value, isn't that so ?

That would be scenarios where any kind of notification to the service
monitor would be useless. My point is that there are indeed some
scenarios where notification can be helpful, and that's only what that
lib is for.


--mtx