New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Trigger added immediately after watch added doesn't work #35
Comments
Actually it's not the fault of the wrapping Ruby program - the problem seems to be about timing. I've boiled down the Ruby script to a simple Bash script:
When run, triggers won't work, but when uncommenting the |
Ah, this is probably a race with the initial crawl of the tree. Watches and triggers persist across a watchman process restart, so hopefully you wouldn't hit this problem especially frequently. |
can you clarify: "the trigger never fires" Does this mean that it never ever fires, or that it doesn't fire while your script is running, but does when you later touch a .py file? |
Ah thanks. I may add a 5 second sleep just to be extra safe. Would love to know when this is fixed. I meant that it never fires, meaning I can touch *.py files at any time and they will never fire the trigger, even though the trigger shows up just fine in the |
I can't reproduce this. Where are you looking for the echo output? It goes to the watchman log, which is typically |
I've been tailing |
Can you attach your log file or otherwise get me a copy? |
The log file is not interesting, it only outputs 'WORKING' when I've slept a bit before adding the trigger, then touched a .py file, and outputs nothing when I don't sleep at all before adding the trigger. Here are the word counts you requested:
and for .py files:
|
Actually every time I run the script I also get at the beginning of
|
I'm actually still seeing the behavior of the trigger not firing, even when adding it with a 5 second delay after the watch add. I don't see the behavior immediately after adding the trigger but I do see after watchman's been running for some time. Maybe this is due to a host suspend/resume? I am running watchman on Mac OS X. |
Can you send me a complete log file when this happens? I wonder if there is evidence of something going awry in there |
I've been able to reproduce this every time:
So looks like Watchman is being restart after a sleep/resume, and somehow getting itself into the same bad state as if I didn't use the 5-second delay. Any insight into this? |
Ok I'll attempt to outline the commands that I run and the subsequent output in the log: $ ../vmsetup/watchman/watchman watch-del /Users/cf/foo && pkill watchman && {command that runs watchman with trigger} && touch foo.py output in log: $ ps -ef | grep watchma[n] (then i sleep and resume my computer) after a few seconds, new output in log: $ ps -ef | grep watchma[n] $ touch foo.py (nothing in log) |
I think something weird is going on, because it looks like your watchman process got restarted. If you'd like to try to debug this more in realtime, I'm hanging out in #watchman on freenode. Stuff I'd like to know:
If you re-run your test, please also run |
Hey Wez, sorry for the delay (vacation). Here's the answers to your questions:
I'll try pinging you on freenode |
Did you get to the bottom of this? |
Wez, |
Now that the restart thing is cleared up, can you get me a reliable repro for the sleep thing? I can't see anything obvious that would cause it to be required |
I am using a Ruby program to automate the creation of a watched directory and trigger. Adding a trigger seems to work (running the 'trigger-list' command shows it), but the trigger never fires. Running the same exact 'trigger' command to add the trigger, but directly on the terminal, works just fine.
Is it something to do with environment?
The text was updated successfully, but these errors were encountered: