Enrico Weigelt:
> 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.

What you are requesting is that developers should learn a new api for
the same end as the old, I won't support that. What is wrong with
daemon(3) ?

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

I'd say that the individual program has no need nor any interest of any
pid file, it will be running just as fine without it.

A pid file is only in the interest of a monitoring program, so why not
let the monitor create it for it's own use, why clutter all idividual
programs with it.

And, you didn't answer the question, is there anything besides the pid and
the state that a monitoring program needs to know ?

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

If you "do it there", you are actually doing it within the individual
program, and if you are so fond of replacing standard libc calls, why
don't you go the fakeroot route:

fakeroot works by replacing the file manipulation library functions
(chmod(2), stat(2) etc.) by ones that simulate the effect the real library
functions would have had, had the user really been root. These wrapper
functions are in a shared library /usr/lib/libfakeroot.so* which is loaded
through the LD_PRELOAD mechanism of the dynamic loader. (See ld.so(8))

Then you won't need to change any program, your monitor just provides a
libc wrapper containing the wrappers for whatever functions it fancy
monitoring. Why do I have to modify "my" source code just to please a
monitor ?

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

Well there you have your service notification, it is already
implemented. Why don't you use it ?
And if you really care about the mail server, you look in its logs.

And, in parenting a child, you always need to know something about
the child.

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

So what are thoose scenarios, if you really want monitoring you could
use simple setups of mon or nagios. At the other end is: just start the
program, if it dies, you investigate and complain to upstream.

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

So, this is only about staggered startup at root ?
Why don't other programs just sleep() and retry till the problem is
gone. You have the same problem if your db is on one box, you dns
server is on another, etc. Or do you propose that the monitor should
run multihost ?

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

Yea, I only heard the scenario booting so far, so why bother ?

Regards,
/Karl Hammar

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