Anyone here using distccd inside a chroot jail on Linux?
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
http://lists.samba.org/mailman/listinfo/distcc
[EMAIL PROTECTED] wrote:
However, when I have multiple builds going at the same time, using the same set of servers, I get one of the following three messages.
distccmon-text[10782] (dcc_close) ERROR: failed to close fd4: Stale NFS file handle
or
distccmon-text[960] (dcc_mon_read_state) Warning:
[EMAIL PROTECTED] wrote:
I pursued the DISTCC_DIR angle first.
I think by default this environment variable is set to your $HOME/.distcc directory which in our setup is NFS mounted on a Netapps box.
While I have only run the test ONCE, setting the DISTCC_DIR=/tmp/ahasty/.distcc resulted in a
Dag Wieers wrote:
Has anyone done any work on making an e.g. Knoppix bootable cd that makes a
distcc daemon and gcc available to the local LAN? This would be handy for
doing kernel/KDE/GNOME builds in an office full of Windows PC's for example.
No, but I'm putting together a hetrogenous cluster of
Cosmin Pop wrote:
(I'd like to be able to provide a link to a Cygwin-hosted Linux-target gcc
binary that people can simply download and use. Please contact me if you can
provide one. -- mbp) - from http://distcc.samba.org/faq.html
I don't know if this is of any help to you, but there is a topic
Jiann-Ming Su wrote:
gcc 3.3.3 is housed on /opt/gnu. The helper system nfs mounts /opt read-only.
If I simply do a make, fluxbox and qt gets built correctly.
I passed --verbose to distcc, and I see errors on the console when trying
to build qt:
distcc[26444] (dcc_mkdir) ERROR: mkdir
Martin Pool wrote:
It would be nice if we could secure distcc without slowing it down,
as I believe ssh does.
Yes, SSH does slow it down. A certain amount of slowdown is probably
unavoidable compared to just blatting out bulk data over TCP, but it
need not be so large.
To avoid the overhead of
Jake McGuire wrote:
I am planning to start working on adding load management enhancements to
distcc for use at our company, but wanted to make sure that no one was
almost done fixing the problem and also make sure that I didn't spend a
bunch of time making my changes and have them rejected.
I'm
Wayne Davison wrote:
Here's an idea I had been kicking around for awhile but never got to.
All systems that want to make distcc requests need at least one local
server process. This server would be responsible for talking with the
other servers that were around (configured in some manner),
Jake McGuire wrote:
I don't think blasting all N servers with a UDP packet on
each distcc run is a good idea.
It depends on the size of your preprocessed file. The one preprocessed
file that I looked at from our build was 1.5 megabytes; compared to a
thousand TCP packets, plus acks, plus
Martin Pool wrote:
Please look at the notes on this in the TODO and protocol-3.txt
documents in the source distribution.
Unfortunately, protocol-3.txt isn't in the current release,
and you don't have a web gateway set up so we can look at
the arch repository yet.
Is this a clever ploy to get us to
Justin Randall wrote:
I am planning to start working on adding load management enhancements ...
3) on startup, distcc determines appropriate server to send request to
a) poll all servers in host list - wait until all respond or 0.1
seconds, whichever comes first
b) multiply connection count
Martin Pool wrote:
Thank you for the patch. It looks OK to me, except that I am not sure
if it should be an option specified in that way. I wonder if it
should always be on? Or at least, if it should always be on until we
have some kind of automatic weighting of faster machines.
People are used
Caleb Groom wrote:
I'm trying to use distcc to compile GNOME via GARNOME across 3 computers
- 1 client machine and two distcc servers. The client and one server
will compile, however the second server will not. I'm willing to
compile any package, GARNOME is just my first choice.
In the spirit of
Martin Eisenhardt wrote:
will the two pathces for the randomization of distcc's host list and the
setting of a connection timeout be merged into the main trunk of distcc?
If so, when will that happen?
I'm all for the randomization patch being merged :-)
but which timeout patch are you referring
Martin Eisenhardt wrote:
Sound reasonable to me. How many hosts are in your cluster?
And are they all roughly the same performance?
There are as many as 25 [EMAIL PROTECTED], one 2-way server with [EMAIL PROTECTED]
and a
couple of desktop systems across the department.
OK, so it sounds like the
Verma, Ajay wrote:
Thanks Martin,
I create my Makefile using autoconf and automake and it works fine
without -j.I am attaching my makefile. Could you pls let me know how to
find what is missing in my Makefile.
Please don't ask Martin to fix your Makefile, it's rude, he's
got enough work
Martin Pool wrote:
Yes, one thing I wanted to do was to allow the client to control the
input and output filenames, which implies a clean directory for each
job.
Yup. Should the client have to specify which files it wants
back, or should the server just send back everything new?
(And I have to
Ralf Corsepius wrote:
(I still don't know how to
make a single .SRPM for multiple targets, though.
It's darn complicated ;)
From my experience (I am the author of the RTEMS cross toolchain
rpm-specs), if you really want to provide a single SRPM, you probably
will have to resort to passing the
Daniel Kegel wrote:
Ralf Corsepius wrote:
(I still don't know how to
make a single .SRPM for multiple targets, though.
It's darn complicated ;)
From my experience (I am the author of the RTEMS cross toolchain
rpm-specs), if you really want to provide a single SRPM, you probably
will have
[EMAIL PROTECTED] wrote:
Could distcc installation include creating the masquerade directory,
please?
I'm using the Debian distcc 2.16-1 package. The distcc documentation
recommends creating a masquerade directory in /usr/lib/distcc/bin. This
directory is pretty important; I'd like to count on
Dimitri Papadopoulos-Orfanos wrote:
I've updated distcc from 2.16 to 2.17 and I'm experiencing crashes.
The crash seems to be related to changes in the client part of distcc
because:
- I can reproduce the crashes with
* server distccd 2.16 + client distcc 2.17
* server distccd 2.17 + client
Jean Delvare wrote:
- Try to vet the command line; allow only particular commands. It's
not enough to just say only run gcc because an attacker might
try to send output to a file. This couldn't give total protection
but it might help.
I wouldn't analyze the whole command line, since it
Roberto wrote:
http://distcc.samba.org/faq.html#cross-compile
where you said this
/ (I'd like to be able to provide a link to a Cygwin-hosted
Linux-target gcc binary that people can simply download and use.
Please contact me if you can provide one. --
I haven't pinned blame yet, but since I switched from
distcc-2.14 to distcc-2.16, I've had stability problems.
Has anyone else noticed anything like this?
It could also be my hardware, so I'm not sure it's distcc's
fault.
- Dan
__
distcc mailing listhttp://distcc.samba.org/
To
Victor Norman wrote:
All,
I'm trying to roll-out the use of distcc here in our organization among our 70
or so software engineers (see previous post My big plans for distcc). I'm
running into a few issues with multiple engineers doing compiles at once. Here
are the specs: distcc2.16 on
Victor Norman wrote:
--- Daniel Kegel [EMAIL PROTECTED] wrote:
I don't think you should be sharing a .distcc directory between
multiple users. It's not a common configuration, and there are
sure to be problems.
Does the community agree? I thought this was the recommended setup.
http
Jake McGuire wrote:
File locking over NFS is a complex operation, much more so than on a
local disk, and distcc can do a whole lot of it. Depending on the
network and the load on the cluster, I'd not be surprised if the file
locking took more time than actually distributing the .i file and
Victor Norman wrote:
I'd love to hear was others think of this data, and my conclusions. And, I
will be posting my Python code as soon as I iron out some ugliness, etc. If
you want it with its ugliness intact, please let me know.
Bravo! Sounds like solid benchmarking of a large group using a
Martin Pool wrote:
Even my massive employer manages to get by with only about 4 class-A
networks. Do you really have more than that?
Some companies don't have a monolithic network, and it might be
hard to get a list of all the networks you'd have to allow...
- Dan
__
distcc mailing list
Victor Norman wrote:
Dan, Jean, et al.,
I have taken Dan up on his challenge (sort of). I ran 6 compiles
simultaneously, each with its own DISTCC_DIR, and with host list randomization
turned on, and -j20. What I found is that the compilation times increased
pretty significantly: from 39
Martin Pool wrote:
On Mon, 18 Oct 2004 09:05:20 -0500, Yang Tj-ATY010
I am not familiar with C++ at all, can someone
give me an pointer on how to make up the C++ test
case ?
Try building a large C++ program. The STL might be a good stress test.
Yeah, or ACE or TAO/ACE, which probably have
Jean Delvare wrote:
I found that I need the following patch for distcc (2.18.1) to work on
my SunOS 5.8 workstation at work. Looks like on this system, connect(2)
won't reset errno to 0 when successful. I guess this is a broken
behavior to have, but the workaround in the distcc code isn't too
[EMAIL PROTECTED] wrote:
I just inherited the duty of overseeing the build system for a fairly large
project. The project's native C components target the following
architechtures-OSs:
IA32-linux
S390-Linux
IA32-windows
SPARC-Solaris
RISC-HPUX
PPC-AIX
S390-ZOS
ISeries-OS400 (yes, I know)
Our
[EMAIL PROTECTED] wrote:
Daniel Kegel wrote:
Building linux-{windows,solaris,hpux,zos,os400}
cross-compilers is a Big Hairy Deal
No problems with linux/i386 - solaris/sparc cross-gcc :)
Sure, but it gets hairier when you want it for five platforms.
Also, no problem assumes you've figured out how
George Garvey wrote:
On Fri, Nov 12, 2004 at 11:56:01PM +0300, [EMAIL PROTECTED] wrote:
Daniel Kegel wrote:
Building linux-{windows,solaris,hpux,zos,os400}
cross-compilers is a Big Hairy Deal
No problems with linux/i386 - solaris/sparc cross-gcc :)
Similar report here: linux/x86 (both intel
Greg Earle wrote:
Figure out how to make distcc work with the Sun C compiler
and your students will be heroes to many :)
Ditto for icc, probably.
(Hi Greg!)
- Dan
__
distcc mailing listhttp://distcc.samba.org/
To unsubscribe or change options:
Martin Pool wrote:
OK, distcc (in arch head, will be 2.18.4) now runs anything with -d
locally. This will at least make it correct. Bringing the debug
output back from the remote machine will require a protocol change.
(Is it really worth it? How many people do all their builds with
compiler
Martin Pool wrote:
What about the use of fork? If the problem is that fork is slow, then
using --no-fork should not make much difference because the forking
happens only at startup and then every hundred jobs or so.
If fork is a problem, it would be more useful to replace the forks
which happen
Zahari Doychev wrote:
Hi all,
I am new to distcc and I am not sure that it is the thing that's right
for me.
I have windows box and several linux boxes. I want to write and edit all
my code on windows machine and then compile it for one of the linux
boxes.
All my programs are
Donohue, Michael wrote:
Last, the localhost lock file now includes part of the host name. We
have 4 localhosts in use here on shared disks. Without this change,
they all used the same lockfiles. This meant that box 2 would not do
any linking, because box 1 was already doing 4. ...
One
Jean Delvare wrote:
Only the hosts after --randomize are randomized, I think.
True, but I still second Victor's point of view. The host file contains
hosts, and adding options there doesn't sound good at all. Not that I
have an immediate idea to implement the not all hosts are randomized
concept,
Donohue, Michael wrote:
I would like to get my patches considered for inclusion, but they seem
to be held up by not having a proper place to configure flags. I dont
find using the hosts file all that objectionable, since I want to be
able to control these on a system wide basis. This means
Donohue, Michael wrote:
The other change is to randomize host selection, and choose based on
slots. This means that hosts with 4 available slots are 4 times more
likely to be chosen than a host with only 1 available slot.
OK, I'm sold on the approach. Josh and I now feel silly for randomizing
Donohue, Michael wrote:
I would like to get my patches considered for inclusion, but they seem
to be held up by not having a proper place to configure flags. I dont
find using the hosts file all that objectionable, since I want to be
able to control these on a system wide basis. This means
Ryan Churches wrote:
well i found a fellow named Dan Kegals website http://kegal.com and he
makes a crosscompiler script for *nix platforms that will build one to
your liking. so i installed it, and it built the cross compiler in a
few hours. very automagic when used with wget.
That's
Avuton Olrich wrote:
I have a really slow machine and two faster ones, I am compiling on
the slow machine and I would rather it be idle than compiled on. I do
not have it in the get hosts but I do see a few cc1plus in the top
output and 0% idle. Here's the simple question: Is localhost added by
Jeremy Glazman wrote:
After some more rigorous testing, it appears that the problem is a race
condition. Somehow make (in parallel) is trying to build the libraries and
the binary that depends on them at the same time. Then when the binary is
finished compiling it tries to link, and the
The --allow option is now mandatory for distcc's daemon mode.
This is a good thing; I hate letting somebody else's
Aunt Tilly have the ability to run processes on my box :-)
But it presents a challenge for those packaging
distccd up as an rpm. The rpm comes with an /etc/init.d script
to start
Josh Patterson wrote:
I have been happily using Distcc for about a month now, but have encountered
weirdness with regard to what Assembler tries to get used. In some cases for
reasons that I don't understand distccd tries to use a native version of AS,
instead of PPC_405-as which would make more
Martin Pool wrote:
There is an idea from some time ago that distcc should do
load-balancing, etc by server IP address, rather than hostname. If we
did that, then you could perhaps just have one round-robin DNS address
per site. If the machine's default domain was set properly it would
be
Martin Pool wrote:
It seems like this approximates the other proposed behaviour of having
distcc.$SITE.company.com have A records for all the servers, and then
doing locking etc by ip address. It has the advantage of requiring
less cooperation from the DNS administrators, but the disadvantage
Greg Szeszko (TT) wrote:
It appears that the -E option of g++ prevents use of precompiled headers
(pch). The result is a preprocessed file, but correct .h.gch files are
not pulled in. This is a problem when g++ and pch are used by distcc.
Before distcc sends a job to a remote machine, it
Greg Szeszko (TT) wrote:
Thanks. This option must be new in GCC4.x. I am using 3.4.3 and it
doesn't know anything about -fpch-preprocess. Is there anything in
3.4.3 that can be used to achieve the same goal?
No. And gcc-3.4 doesn't support PCH anyway, so you
shouldn't be using it there,
dcc_connect_by_addr does not check for the result
of the connect properly. Once the fd is writable, you
have to retrieve the connect's completion status using getsockopt
SO_ERROR. I noticed this when I modified lsdistcc to use dcc_connect_by_addr,
and it started returning a much larger list of
I'm seeing a funny problem. (This is with distcc 2.18.3.)
In fact, I saw this several months ago, and rebooting
all the servers fixed it then, but this time I looked
at it in a bit more detail.
Every other build of a big app, the client will hang on some random file;
netstat on the client shows
Looks like the comment in src/sendfile.c
* Our sockets are never non-blocking, so that seems to me to say that
* the kernel will never return EAGAIN -- we will always either send
* the whole thing or get an error. Is that really true?
needs updating, since the socket was set to nonblocking in
I'm working on the following enhancements to distcc,
all motivated by observing shortcomings in real use
in a demanding environment:
1. gcc-2.95.3 sometimes spins on invalid input. The user eventually
aborts the build, but distccd does not then kill the compile job.
Distccd should kill
On Mon, 21 Nov 2005, Victor Norman wrote:
Recall that I wrote a system in python that uses distcc to provide
1. load balancing, with multiple servers and multiple users, taking into
consideration the loads on the server machines,
2. multi-os support -- use linux, cygwin, solaris,
On Sun, 27 Nov 2005, Laurent Calburtin wrote:
I'm very interested about combining ccache and distcc. I think that
would make a huge performance improvement in our situation where many
developers are compiling each day roughly the same set of files.
But installing ccache on each distccd
60 matches
Mail list logo
