:: Re: [DNG] tiny service state api [W…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: karl
Fecha:  
A: dng
Asunto: Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]
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 ?

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

Also, given that you can do the above without this lib opens gives the
program the option too cheat, say, if the monitor wishes to have a
tight control of the process.

A reliable (well, we have to trust the kernel) way to get the pid
and uid of a sender is through signals, are there any other ways ?

> * srvmgt_report_state(...)

--> report the service state to the supervisor
...

There could be something like *_a_would_like_to_be_monitored() and
*_I_wish_to_regain_my_free_will().

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

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

///

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

Given the lib suggestion, it seems that we are trusting the program.
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 ?

Regards,
/Karl Hammar

-----------------------------------------------------------------------
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57