httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randy Terbush <ra...@zyzzyva.com>
Subject Re: phase II
Date Thu, 25 May 1995 12:23:15 GMT
>    1. Only one logger daemon can read from a pipe at one time. Aside from 
>    using sockets, the only solution I see to this is to provide a "spigot"
>    that is capable of increasing the number of pipes as they are requested.
>    I am beginning to prefer the idea of the server providing a socket
>    interface for these little suckers to attach to.  The server could
>    either be writing the same information to all established sockets,
>    or we could provide a per socket configuration for the information.
> 
> Hmmm... if you're willing to forgo the ability to set up and tear down
> loggers without having to restart the server (or at least have it
> reread its config files), then this could also be done by having a
> "hub" process which takes all output from the one pipe coming from the
> actual server process(es), and distributes it among the other loggers
> that are active.
> 
> (In fact, even if you *do* want to be able to set up and tear down
> loggers without disturbing the server proper, having the loggers
> connect to a separate "log hub", which gets a single pipe from the
> real server might well be the easiest way to go, particularly in the
> non-forking model; otherwise, for the non-forking model the pipes to
> new logger daemons would have to be distributed to currently running
> child processes via some kind of privilege transfer, which is (as
> we've seen) not supported on all reasonable systems).
> 
> rst

Good point.  I was not thinking of the mulit-process model....
This is what I was suggesting with the "spigot" idea.  

Give me some implementation suggestions.  I think this process
should be written in C.  

It seems that in this case, writing everything to 1 named pipe
would be best.  The "log hub" would then read from this pipe
and offer socket connections to the logging daemons?

Should this hub be given some smarts with a "logging protocol"
where the attaching daemon process could request logging info
in a certain language, format, etc?  I guess there is really
nothing that is language dependant in what we are logging...








Mime
View raw message