Hi,
today I tried setting up the xenofarm client to compile pike on my Mac. It is running MacOS 10.3.5 (i.e. Darwin 7.5.0) and fink. Compiling Pike suceeds (I've tried it outside xenofarm), but xenofarm fails when assembling the result with the following lines from the xeonfarmclient.txt:
BEGIN response_assembly PASS END cd build/xenofarm && tar cf - . > ../../xenofarm_result.tar tar: ./compilelog.txt: file changed as we read it tar: Error exit delayed from previous errors make: *** [xenofarm] Error 2
Any clues on how to fix this error?
cheers, Mikael
In the last episode (Aug 20), Mikael Brandstrm said:
today I tried setting up the xenofarm client to compile pike on my Mac. It is running MacOS 10.3.5 (i.e. Darwin 7.5.0) and fink. Compiling Pike suceeds (I've tried it outside xenofarm), but xenofarm fails when assembling the result with the following lines from the xeonfarmclient.txt:
BEGIN response_assembly PASS END cd build/xenofarm && tar cf - . > ../../xenofarm_result.tar tar: ./compilelog.txt: file changed as we read it tar: Error exit delayed from previous errors make: *** [xenofarm] Error 2
I don't know why you're getting the error, but --ignore-failed-read will make tar treat it as a warning (tar is used 3 places in client.sh). GNU tar stats the file before and after reading it, and if the ctime is different, it prints that message.
Thanks, I have been looking through the xenofarm.sh in pike and see no reason there either to the file changing size. I will give your tip a try and see what happens.
// Mikael
Dan Nelson wrote:
In the last episode (Aug 20), Mikael Brandstrm said:
today I tried setting up the xenofarm client to compile pike on my Mac. It is running MacOS 10.3.5 (i.e. Darwin 7.5.0) and fink. Compiling Pike suceeds (I've tried it outside xenofarm), but xenofarm fails when assembling the result with the following lines from the xeonfarmclient.txt:
BEGIN response_assembly PASS END cd build/xenofarm && tar cf - . > ../../xenofarm_result.tar tar: ./compilelog.txt: file changed as we read it tar: Error exit delayed from previous errors make: *** [xenofarm] Error 2
I don't know why you're getting the error, but --ignore-failed-read will make tar treat it as a warning (tar is used 3 places in client.sh). GNU tar stats the file before and after reading it, and if the ctime is different, it prints that message.
I was wrong. The tar command generating the error is found within Pike's Makefile. For some reason it fails when run within xenofarm, but not when I run it stand-alone. It seems like I have to do some more debugging to pin down the problem.
// Mikael
Mikael Brandström wrote:
Thanks, I have been looking through the xenofarm.sh in pike and see no reason there either to the file changing size. I will give your tip a try and see what happens.
// Mikael
Dan Nelson wrote:
In the last episode (Aug 20), Mikael Brandstrm said:
today I tried setting up the xenofarm client to compile pike on my Mac. It is running MacOS 10.3.5 (i.e. Darwin 7.5.0) and fink. Compiling Pike suceeds (I've tried it outside xenofarm), but xenofarm fails when assembling the result with the following lines from the xeonfarmclient.txt:
BEGIN response_assembly PASS END cd build/xenofarm && tar cf - . > ../../xenofarm_result.tar tar: ./compilelog.txt: file changed as we read it tar: Error exit delayed from previous errors make: *** [xenofarm] Error 2
I don't know why you're getting the error, but --ignore-failed-read will make tar treat it as a warning (tar is used 3 places in client.sh). GNU tar stats the file before and after reading it, and if the ctime is different, it prints that message.
Things seems odd. I tried adding ls statements around the offending tar line (second to last line in the xenofarm target), then it worked. When I removed those ls statements, it worked, and now when I try using the pike farm client, it fails again.
Is the --ignore-failed-read option POSIX or GNU? Does Pike currently have any requirements on tar in the build environment? If --ignore-failed-read is POSIX or if Pike can be let to require a tar which understands the option, shall we patch the Makefile to make use of --ignore-failed-read for the xenofarm target? Otherwise, are there any other suggestions on how to fix this problem?
// Mikael
Mikael Brandström wrote:
I was wrong. The tar command generating the error is found within Pike's Makefile. For some reason it fails when run within xenofarm, but not when I run it stand-alone. It seems like I have to do some more debugging to pin down the problem.
// Mikael
Mikael Brandström wrote:
Thanks, I have been looking through the xenofarm.sh in pike and see no reason there either to the file changing size. I will give your tip a try and see what happens.
// Mikael
Dan Nelson wrote:
In the last episode (Aug 20), Mikael Brandstrm said:
today I tried setting up the xenofarm client to compile pike on my Mac. It is running MacOS 10.3.5 (i.e. Darwin 7.5.0) and fink. Compiling Pike suceeds (I've tried it outside xenofarm), but xenofarm fails when assembling the result with the following lines from the xeonfarmclient.txt:
BEGIN response_assembly PASS END cd build/xenofarm && tar cf - . > ../../xenofarm_result.tar tar: ./compilelog.txt: file changed as we read it tar: Error exit delayed from previous errors make: *** [xenofarm] Error 2
I don't know why you're getting the error, but --ignore-failed-read will make tar treat it as a warning (tar is used 3 places in client.sh). GNU tar stats the file before and after reading it, and if the ctime is different, it prints that message.
If the option starts with "--"* you can pretty much bet it's not Posix. Demanding a GNU compatible tar is not an option. If you a add "sync" (or MacOS X equivalent) before tar, does it work better?
* Send a thankful thought in Aronsson direction that we don't have to type "-=". See http://www.gnu.org/fun/jokes/long-options.html.
/ Peter Bortas
Previous text:
2004-08-20 20:04: Subject: Re: Pikefarm client problem
Things seems odd. I tried adding ls statements around the offending tar line (second to last line in the xenofarm target), then it worked. When I removed those ls statements, it worked, and now when I try using the pike farm client, it fails again.
Is the --ignore-failed-read option POSIX or GNU? Does Pike currently have any requirements on tar in the build environment? If --ignore-failed-read is POSIX or if Pike can be let to require a tar which understands the option, shall we patch the Makefile to make use of --ignore-failed-read for the xenofarm target? Otherwise, are there any other suggestions on how to fix this problem?
// Mikael
Mikael Brandström wrote:
I was wrong. The tar command generating the error is found within Pike's Makefile. For some reason it fails when run within xenofarm, but not when I run it stand-alone. It seems like I have to do some more debugging to pin down the problem.
// Mikael
Mikael Brandström wrote:
Thanks, I have been looking through the xenofarm.sh in pike and see no reason there either to the file changing size. I will give your tip a try and see what happens.
// Mikael
Dan Nelson wrote:
In the last episode (Aug 20), Mikael Brandstrm said:
today I tried setting up the xenofarm client to compile pike on my Mac. It is running MacOS 10.3.5 (i.e. Darwin 7.5.0) and fink. Compiling Pike suceeds (I've tried it outside xenofarm), but xenofarm fails when assembling the result with the following lines from the xeonfarmclient.txt:
BEGIN response_assembly PASS END cd build/xenofarm && tar cf - . > ../../xenofarm_result.tar tar: ./compilelog.txt: file changed as we read it tar: Error exit delayed from previous errors make: *** [xenofarm] Error 2
I don't know why you're getting the error, but --ignore-failed-read will make tar treat it as a warning (tar is used 3 places in client.sh). GNU tar stats the file before and after reading it, and if the ctime is different, it prints that message.
/ Brevbäraren
Ok. That was my bet, on both answers. I've modified my local makefile to do a sync prior to tar. Still it seems cludgy to have such a solution in the Makefile. I suppose sync is fairly standard on systems pike compile on through the xenofarm client, isn't it?
// Mikael
Peter Bortas @ Pike developers forum wrote:
If the option starts with "--"* you can pretty much bet it's not Posix. Demanding a GNU compatible tar is not an option. If you a add "sync" (or MacOS X equivalent) before tar, does it work better?
- Send a thankful thought in Aronsson direction that we don't have to type "-=". See http://www.gnu.org/fun/jokes/long-options.html.
/ Peter Bortas
Previous text:
2004-08-20 20:04: Subject: Re: Pikefarm client problem
Things seems odd. I tried adding ls statements around the offending tar line (second to last line in the xenofarm target), then it worked. When I removed those ls statements, it worked, and now when I try using the pike farm client, it fails again.
Is the --ignore-failed-read option POSIX or GNU? Does Pike currently have any requirements on tar in the build environment? If --ignore-failed-read is POSIX or if Pike can be let to require a tar which understands the option, shall we patch the Makefile to make use of --ignore-failed-read for the xenofarm target? Otherwise, are there any other suggestions on how to fix this problem?
// Mikael
Mikael Brandström wrote:
I was wrong. The tar command generating the error is found within Pike's Makefile. For some reason it fails when run within xenofarm, but not when I run it stand-alone. It seems like I have to do some more debugging to pin down the problem.
// Mikael
Mikael Brandström wrote:
Thanks, I have been looking through the xenofarm.sh in pike and see no reason there either to the file changing size. I will give your tip a try and see what happens.
// Mikael
Dan Nelson wrote:
In the last episode (Aug 20), Mikael Brandstrm said:
today I tried setting up the xenofarm client to compile pike on my Mac. It is running MacOS 10.3.5 (i.e. Darwin 7.5.0) and fink. Compiling Pike suceeds (I've tried it outside xenofarm), but xenofarm fails when assembling the result with the following lines from the xeonfarmclient.txt:
BEGIN response_assembly PASS END cd build/xenofarm && tar cf - . > ../../xenofarm_result.tar tar: ./compilelog.txt: file changed as we read it tar: Error exit delayed from previous errors make: *** [xenofarm] Error 2
I don't know why you're getting the error, but --ignore-failed-read will make tar treat it as a warning (tar is used 3 places in client.sh). GNU tar stats the file before and after reading it, and if the ctime is different, it prints that message.
/ Brevbäraren
sync exists on a lot of systems, but not all. That sync helps suggests that the OS i broken. the kernel disk layer should keep the view of the disk consistent ragardless of what has hit real media and what is still in memory.
check in "#FIXME: Required by one MacOS machine. Broken kernel disk layer? sync >/dev/null 2>&1"
/ Peter Bortas
Previous text:
2004-08-21 02:32: Subject: Re: Pikefarm client problem
Ok. That was my bet, on both answers. I've modified my local makefile to do a sync prior to tar. Still it seems cludgy to have such a solution in the Makefile. I suppose sync is fairly standard on systems pike compile on through the xenofarm client, isn't it?
// Mikael
Peter Bortas @ Pike developers forum wrote:
If the option starts with "--"* you can pretty much bet it's not Posix. Demanding a GNU compatible tar is not an option. If you a add "sync" (or MacOS X equivalent) before tar, does it work better?
- Send a thankful thought in Aronsson direction that we don't have to type "-=". See http://www.gnu.org/fun/jokes/long-options.html.
/ Peter Bortas
Previous text:
2004-08-20 20:04: Subject: Re: Pikefarm client problem
Things seems odd. I tried adding ls statements around the offending tar line (second to last line in the xenofarm target), then it worked. When I removed those ls statements, it worked, and now when I try using the pike farm client, it fails again.
Is the --ignore-failed-read option POSIX or GNU? Does Pike currently have any requirements on tar in the build environment? If --ignore-failed-read is POSIX or if Pike can be let to require a tar which understands the option, shall we patch the Makefile to make use of --ignore-failed-read for the xenofarm target? Otherwise, are there any other suggestions on how to fix this problem?
// Mikael
Mikael Brandström wrote:
I was wrong. The tar command generating the error is found within Pike's Makefile. For some reason it fails when run within xenofarm, but not when I run it stand-alone. It seems like I have to do some more debugging to pin down the problem.
// Mikael
Mikael Brandström wrote:
Thanks, I have been looking through the xenofarm.sh in pike and see no reason there either to the file changing size. I will give your tip a try and see what happens.
// Mikael
Dan Nelson wrote:
In the last episode (Aug 20), Mikael Brandstrm said:
>today I tried setting up the xenofarm client to compile pike on my >Mac. It is running MacOS 10.3.5 (i.e. Darwin 7.5.0) and fink. >Compiling Pike suceeds (I've tried it outside xenofarm), but xenofarm >fails when assembling the result with the following lines from the >xeonfarmclient.txt: > >BEGIN response_assembly >PASS >END >cd build/xenofarm && tar cf - . > ../../xenofarm_result.tar >tar: ./compilelog.txt: file changed as we read it >tar: Error exit delayed from previous errors >make: *** [xenofarm] Error 2
I don't know why you're getting the error, but --ignore-failed-read will make tar treat it as a warning (tar is used 3 places in client.sh). GNU tar stats the file before and after reading it, and if the ctime is different, it prints that message.
/ Brevbäraren
/ Brevbäraren
In the last episode (Aug 21), Peter Bortas @ Pike developers forum said:
sync exists on a lot of systems, but not all. That sync helps suggests that the OS i broken. the kernel disk layer should keep the view of the disk consistent ragardless of what has hit real media and what is still in memory.
If it's always the same file at fault, it might be interesting to print the results of ls -l on the file just before and after the tar run (or modify gtar to print the two values at part of the error message).
Dan Nelson wrote:
If it's always the same file at fault, it might be interesting to print the results of ls -l on the file just before and after the tar run (or modify gtar to print the two values at part of the error message).
It is, but adding an ls statment before and after fixes the problem. I might try the option to modify gtar to see what's going on. And consider using a modified tar which is not as picky for my xenofarm environment. Seems like the cleanest solution unless someone else is striken by the same problem.
// Mikael
To (hopefully) end this story. I replaced the gnu tar shipped with this version of MacOS with a more recent version. Now the xenofarm target seems to work, and flaerp.naetet.net appears on the Pikefarm result page. (7.4 now, 7.6 and 7.7 on the way).
Thanks for your help! // Mikael
No worry, sync did not fix it.
Mikael
Peter Bortas @ Pike developers forum wrote:
sync exists on a lot of systems, but not all. That sync helps suggests that the OS i broken. the kernel disk layer should keep the view of the disk consistent ragardless of what has hit real media and what is still in memory.
check in "#FIXME: Required by one MacOS machine. Broken kernel disk layer? sync >/dev/null 2>&1"
/ Peter Bortas
Previous text:
2004-08-21 02:32: Subject: Re: Pikefarm client problem
Ok. That was my bet, on both answers. I've modified my local makefile to do a sync prior to tar. Still it seems cludgy to have such a solution in the Makefile. I suppose sync is fairly standard on systems pike compile on through the xenofarm client, isn't it?
// Mikael
Peter Bortas @ Pike developers forum wrote:
If the option starts with "--"* you can pretty much bet it's not Posix. Demanding a GNU compatible tar is not an option. If you a add "sync" (or MacOS X equivalent) before tar, does it work better?
- Send a thankful thought in Aronsson direction that we don't have to
type "-=". See http://www.gnu.org/fun/jokes/long-options.html.
/ Peter Bortas
Previous text:
2004-08-20 20:04: Subject: Re: Pikefarm client problem
Things seems odd. I tried adding ls statements around the offending tar line (second to last line in the xenofarm target), then it worked. When I removed those ls statements, it worked, and now when I try using the pike farm client, it fails again.
Is the --ignore-failed-read option POSIX or GNU? Does Pike currently have any requirements on tar in the build environment? If --ignore-failed-read is POSIX or if Pike can be let to require a tar which understands the option, shall we patch the Makefile to make use of --ignore-failed-read for the xenofarm target? Otherwise, are there any other suggestions on how to fix this problem?
// Mikael
Mikael Brandström wrote:
I was wrong. The tar command generating the error is found within Pike's Makefile. For some reason it fails when run within xenofarm, but not when I run it stand-alone. It seems like I have to do some more debugging to pin down the problem.
// Mikael
Mikael Brandström wrote:
Thanks, I have been looking through the xenofarm.sh in pike and see no reason there either to the file changing size. I will give your tip a try and see what happens.
// Mikael
Dan Nelson wrote:
>In the last episode (Aug 20), Mikael Brandstrm said: > > > >>today I tried setting up the xenofarm client to compile pike on my >>Mac. It is running MacOS 10.3.5 (i.e. Darwin 7.5.0) and fink. >>Compiling Pike suceeds (I've tried it outside xenofarm), but xenofarm >>fails when assembling the result with the following lines from the >>xeonfarmclient.txt: >> >>BEGIN response_assembly >>PASS >>END >>cd build/xenofarm && tar cf - . > ../../xenofarm_result.tar >>tar: ./compilelog.txt: file changed as we read it >>tar: Error exit delayed from previous errors >>make: *** [xenofarm] Error 2 > > > > >I don't know why you're getting the error, but --ignore-failed-read >will make tar treat it as a warning (tar is used 3 places in >client.sh). GNU tar stats the file before and after reading it, and if >the ctime is different, it prints that message. >
/ Brevbäraren
/ Brevbäraren
Hm, why would the file change while being read? It's not running two xenofarms at the same time or something (it shouldn't happen anyway, iirc, but...).
Or is tar just buggy?
/ Mirar
Previous text:
2004-08-20 16:39: Subject: Pikefarm client problem
Hi,
today I tried setting up the xenofarm client to compile pike on my Mac. It is running MacOS 10.3.5 (i.e. Darwin 7.5.0) and fink. Compiling Pike suceeds (I've tried it outside xenofarm), but xenofarm fails when assembling the result with the following lines from the xeonfarmclient.txt:
BEGIN response_assembly PASS END cd build/xenofarm && tar cf - . > ../../xenofarm_result.tar tar: ./compilelog.txt: file changed as we read it tar: Error exit delayed from previous errors make: *** [xenofarm] Error 2
Any clues on how to fix this error?
cheers, Mikael
/ Brevbäraren
Maybe because stdout/stderr from tar is sent to the file it is trying to tar up?
/ Fredrik (Naranek) Hubinette (T minus 2 weeks)
Previous text:
2004-08-22 17:10: Subject: Pikefarm client problem
Hm, why would the file change while being read? It's not running two xenofarms at the same time or something (it shouldn't happen anyway, iirc, but...).
Or is tar just buggy?
/ Mirar
That should not be the case here, since compilelog.txt is created by the xenofarm.sh script, which should have terminated by the time tar is called.
// Mikael
Fredrik (Naranek) Hubinette (T minus 2 weeks) @ Pike (-) developers forum wrote:
Maybe because stdout/stderr from tar is sent to the file it is trying to tar up?
/ Fredrik (Naranek) Hubinette (T minus 2 weeks)
Previous text:
2004-08-22 17:10: Subject: Pikefarm client problem
Hm, why would the file change while being read? It's not running two xenofarms at the same time or something (it shouldn't happen anyway, iirc, but...).
Or is tar just buggy?
/ Mirar
That should not be the case here, since compilelog.txt is created by the xenofarm.sh script, which should have terminated by the time tar is called.
If I remember correctly, compilelog.txt is stdout for sections of the script. It could be that some backgrounded script still holds it open.
/ Henrik Grubbström (Lysator)
Previous text:
2004-08-23 11:11: Subject: Re: Pikefarm client problem
That should not be the case here, since compilelog.txt is created by the xenofarm.sh script, which should have terminated by the time tar is called.
// Mikael
Fredrik (Naranek) Hubinette (T minus 2 weeks) @ Pike (-) developers forum wrote:
Maybe because stdout/stderr from tar is sent to the file it is trying to tar up?
/ Fredrik (Naranek) Hubinette (T minus 2 weeks)
Previous text:
2004-08-22 17:10: Subject: Pikefarm client problem
Hm, why would the file change while being read? It's not running two xenofarms at the same time or something (it shouldn't happen anyway, iirc, but...).
Or is tar just buggy?
/ Mirar
/ Brevbäraren
Just holding it open shouldn't make the file change though. If it actually writes something, it should be visible at the end of the file.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2004-08-23 11:14: Subject: Re: Pikefarm client problem
That should not be the case here, since compilelog.txt is created by the xenofarm.sh script, which should have terminated by the time tar is called.
If I remember correctly, compilelog.txt is stdout for sections of the script. It could be that some backgrounded script still holds it open.
/ Henrik Grubbström (Lysator)
If I read correctly, it is only output for the compile step which is output to compilelog.txt and thus should be closed by the shell by the time xenofarm.sh is done. Oddly enough things started to work with a new tar. Might be buggy tar or buggy OS. The latter more probable I suppose.
Now there are results from that machine on pikefarm, but the testsuite fails in two cases (the same) on 7.6 and 7.7, one is some library issue with GL, test_resolve.pike segfaults. The other is in modules/files/ and the socktest.pike test.
For 7.4 it fails with the same two C stack overflows as some other architechures.
Mikael
Henrik GrubbstrXm (Lysator) @ Pike (-) developers forum wrote:
That should not be the case here, since compilelog.txt is created by the xenofarm.sh script, which should have terminated by the time tar is called.
If I remember correctly, compilelog.txt is stdout for sections of the script. It could be that some backgrounded script still holds it open.
/ Henrik Grubbström (Lysator)
Previous text:
2004-08-23 11:11: Subject: Re: Pikefarm client problem
That should not be the case here, since compilelog.txt is created by the xenofarm.sh script, which should have terminated by the time tar is called.
// Mikael
Fredrik (Naranek) Hubinette (T minus 2 weeks) @ Pike (-) developers forum wrote:
Maybe because stdout/stderr from tar is sent to the file it is trying to tar up?
/ Fredrik (Naranek) Hubinette (T minus 2 weeks)
Previous text:
2004-08-22 17:10: Subject: Pikefarm client problem
Hm, why would the file change while being read? It's not running two xenofarms at the same time or something (it shouldn't happen anyway, iirc, but...).
Or is tar just buggy?
/ Mirar
/ Brevbäraren
pike-devel@lists.lysator.liu.se
-
Dan Nelson -
Fredrik (Naranek) Hubinette (T minus 2 weeks) ＠ Pike (-) developers forum -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Mikael Brandström -
Mirar ＠ Pike developers forum
-
Peter Bortas ＠ Pike developers forum