Any comments? On Wed, 4 Dec 2019, 18:14 nikhil jain, <[email protected]> wrote:
> Just for information. > > Issue is not reproduced when replacing stat with safe_stat() which double > checks the file for stale handle. > > thanks > Nikhil > > On Wed, Dec 4, 2019 at 12:51 PM nikhil jain <[email protected]> > wrote: > >> Thanks for all the help. There was another script which was causing issue >> with the signal. I am able to catch the signal in make. >> >> I successfully implemented the remote execution feature in make 3.81 >> >> I need some help. >> My rules execute on different hosts on NFSi submit a job from host 1. >> >> A rule which executes in host A creates a .o file. >> Once it is done, make checks for the next rule which is dependent on this >> one. >> >> But on the submission host while making the dependency graph again, it >> sees that the .o timestamp is not newer which means it is still reading the >> old .o file. >> >> So it doesn't build the target. >> I know this is normal as it is on NFS so latency is there. >> >> But can I do something from make side to cover this latency? I tried >> putting sleep. It works but we don't know what is the optimal sleep value. >> >> Also, sleep slows down the complete build time. >> >> I see a function safe_stat() and now it is convert d to just stat() >> >> What was the difference actually ? Why we moved from safe_stat() to stat? >> >> Is this related to the issue I am facing. >> >> Please provide any help or suggestions from the make side by which I can >> remove this issue. >> >> FYI, I had tried in lsmake from IBM but I was not able to replicate this >> scenario. >> >> Is there something like NFS flushing which I can do from make side ??? >> >> Urgent help needed. Blocking many production releases. >> >> Also, if I touch a single file and try to run it, I am able to reproduce >> the issue. >> >> But if I touch multiple files and then run the build, I don't see issue >> as some file would be updated and seen over NFS on the submission host. >> >> Let me know any pointers to how I can overcome this behaviour. >> >> Thanks >> Nikhil >> >> >> On Tue, 22 Oct 2019, 00:04 Paul Smith, <[email protected]> wrote: >> >>> On Mon, 2019-10-21 at 22:47 +0530, nikhil jain wrote: >>> > see this how it works in makefile. It is part of the target - >>> > >>> > bash-4.1$ cat Makefile >>> > a1: >>> > trap 'USER_INT=1; /bin/echo "terminating, please wait...."' >>> INT; \ >>> > sleep 100 >>> > >>> > bash-4.1$ make >>> > trap 'USER_INT=1; /bin/echo "terminating, please wait...."' INT; \ >>> > sleep 100 >>> > ^Cterminating, please wait.... >>> > make: *** [a1] Error 130 >>> > >>> > see this ? When make was executing sleep 100 , I gave ctrl+c and got >>> > my message " terminating, please wait". It did not go to >>> > fatal_error_signal at all. >>> >>> It DID go to fatal_error_signal(). Why do you think it didn't? Just >>> because your trap was called doesn't mean that make didn't catch the >>> signal. >>> >>>
