On a network of a few machines I would like the monitor to globally view all the running jobs by all users on all machines. Other people might want to monitor that too. That probably implies either a broadcast/multicast setup, or a central daemon that retransmits the notifications.
Because of trust issues, I prefer to avoid broadcast techniques.
I should mention also that I care about compile clusters that are not all located on the same LAN, so broadcast isn't sufficient by itself.
It worries me too. At the very least I wouldn't want it to be on by default. Consider compiling on a laptop connected to a cafe wireless network.
Perhaps monitoring across machines is not a good idea after all.
On the other hand if the monitoring is purely local it might be simplest just to stick with state files.
Let's keep thinking about it. I do think that anyone with permission to use the distcc cluster ought to be able to have an overview of its status of some sort.
By the way, it occurs to me that a local daemon would also be of some use. e.g. it could hold long-lived ssh connections to the compute servers (to save on socket startup time),
That would be good. It's not so much socket startup as crypto
negotiation (DH and so on).
I think this can be done independent of distcc.
Yep, and I bet it's being done somewhere.
and it could cache knowledge of remote machine status.
That's what the generic proxy can't do. Ssh proxing really would be a small part of what the local daemon might do. I can imagine it might be convenient and useful to move some of the logic currently in the distcc wrapper into a local daemon, which by virtue of being long-lived, would be able to do the same thing better and/or faster.
- Dan
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change
__ distcc mailing list http://distcc.samba.org/
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
