Nico Erfurth wrote:
> Tamas TEVESZ wrote:
>
>> On Mon, 8 Jul 2002, George Schlossnagle wrote:
>>
>> > this statement. Hint: I would not execute killall on a system you
>> > don't want rebooted.
>>
>> further hints to those who are interested: on (some) other systems,
>> the equivalent is called `killall5'. _5_ as in system_V_ :)
>>
>> that direction doesn't seem to be what i would take..
>
>
> OkOk, seems like killall is not a generic way ;), maybe the
> Local/Makefile, or the OS-hints should include a option how to handle
> it, because the current solution isn't that good. As i said in my first
> mail, exim is too fast ;)
>
> so, the options are
>
> 1.) slow down exim (i think noone wants this) ;))
> 2.) don't rely on exiwhat
> 3.) make the killmethod system-dependend
> 4.) make the killmethod configureable
> 5.) use some totaly other way
> 6.) don't change anything in the official distribution, if someone needs
> it, he can change it
Yeah , i was thinking about this one when this was discussed at the
conference the other week.....
Since you have a standalone master daemon process, the listener, why not
use that to 'co-ordinate' stuff - i'm not a master of C/C++ IPC (in fact
i hate it and prefer java as a consequence, but i have little love of C
:). The exim processes could tell that, and exiwhat could ask it.
As a side effect, a currently useless concept - a daemon exim that
neither listens or forks queue runners becomes something someone may use
one day just for it's co-ordination powers.
(5) other way :D
plus the exim daemon could keep a small history if that was useful, or
some other short term data - performance times or something. Well,
centralised communications is something exim doesn't do, but doesn't
have too much need for, but since there's the listener hanging around
anyway, give it something else to chew on :)
Iain
