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 <jainnikhi...@gmail.com> 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, <psm...@gnu.org> 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. >> >>
