Re: [CVS] unix socket support added

[Christian Hopp]

On 5 Aug 2002, Jan-Henrik Haukeland wrote:

> Christian Hopp <address@hidden> writes:
>
> > Uiih, a draw.
>
> Seems like we've got ourself into a Mexican standoff :)

Jupp.

> > And you, Hauk, have change your mind about Martins second idea???
>
> Not really, sorry Christian. Let me try to explain in my roundabout
> way.

Maybe I just misunderstood you in the first way when we discussed
Martins options.  Where you said that you are, "Subsidiary I'm +1 for
this suggestion by Martin".  Because I used that as a base to start
the patch.

> First, I'm against it because I haven't seen any good reason for
> adding this, except for when developing monit and when another live
> monit daemon is running in the background. Well, this of course could
> be a nuisance for the developer, but does not really justify adding
> new code to monit, since there are "easy" workarounds in a developing
> milieu.

Definitely!

> If you can give me other (operational) arguments for adding the code,
> I will of course reconsider and probably accept.

I don't know if other users might want to use a different repository
for their pid runtime files. E.g. keeping non os original data away
from os stuff, like the intention of an "opt" directory.  I try that
as long as programs allow it.

In general...  I as a user want to have control over the place where
programs store the data.  That should be possible whether at compile
time or by configuration...  but without fiddling around in the code.
"Compile time" has the main disadvantage that users who want to use
packaged versions of monit can't control this anymore.  Thus, an
configuration option would be the way to choose.

The "developers use" of it _has to_ be secondary.  And of course any
parts which have no use for the user should be kept somehow outside of
the distributed parts, and that includes code.

Okay, the impact of the patch to the code would be five lines to p.y
to add the optional statement "set pidfile" and one to NULL
Run.pidfile initially.  And files.c [void init_files()] would get an
additional if clause to check whether Run.pidfile was already
initialized.

> I'm not particular found of jamming guidelines down my next fellow
> throat, but XP has has a few good ones for the case we are discussing:

Of course you are right on that, and I definitely won't resent that.
Only the discussion of features and methods brings advancement.

(...)
>
> A summary is that you should not add code to an application unless the
> functionality it provides are in common use and important.
>
> :-)

Sorry, I am really stubborn. (-:  Amazing I wrote more in that email
than the patch would have for code+documentation.  But you gotta do
what you gotta do.

And sorry again, I have to change the topic.  Before I spoke of the
possible NFS problems that could come up, when the connection breaks
at the time monit accesses it.  You proposed to use a "timeout"
construction via alarm().  But that won't IHMO work.  Monit won't be
able to evaluate any signal at that time. The exception is, you
specify intr, but then you could be only quitted or stopped.  The only
possible way IHMO would be to fork away the actual checker and
evaluate its exit value.  If you wait() longer than the timeout value
put aside this service until the a wait() is successfully answered and
warn the specific recipient.  Or do you think that this might happen
most unlikely???

Have a nice day,

Christian

-- 
Christian Hopp                                email: address@hidden
Institut für Elektrische Informationstechnik             fon: +49-5323-72-2113
Technische Universität Clausthal                         fax: +49-5323-72-3197
  pgpkey: https://www.iei.tu-clausthal.de/pgp-keys/chopp.key.asc  (2001-11-22)