Failed to identify PDU

[nmalcolm]

After I noticed watchman wasn't executing the script specified I tried to debug the problem.

[root@dev www]# watchman --persistent log-level debug
{
    "version": "2.8.2",
    "log_level": "debug"
}
1381439535: tid=1055180544 failed to identify PDU: 
1381439535: tid=1055180544 unable to talk to your watchman!

Can anyone help me solve this issue? There doesn't seem to be any documentation about why this happens, and it doesn't look like anyone else has encounter this either.

[wez]

I think this might be due an issue with the BSER client in the watchman CLI.
Try this instead:

$ watchman --persistent --server-encoding=json log-level debug

[nmalcolm]

Thanks. I'm now getting a bunch of assessing triggers messages. To clarify, is that to fix the issue with debugging or with watchman not executing scripts? If the latter, is there a way to set server-encoding to json always (I'm assuming that watchman does its own thing with starting up; correct me if I'm wrong)?

[wez]

my comment was about connecting to the debug output. You haven't given any details on your other issue, so it's difficult to say whats's going on. What does watchman trigger-list $root say?

[nmalcolm]

{
    "version": "2.8.2",
    "triggers": [
        {
            "name": "generatestatic",
            "command": [
                "./scripts/celerity_mapper.php ./webroot"
            ],
            "rules": [
                {
                    "pattern": "*.css",
                    "include": true,
                    "negated": false
                }
            ]
        }
    ]
}

Running ./scripts/celerity_mapper.php ./webroot from the root works fine, and git status does show that .css files have been modified. I tried using absolute paths too, to no avail.

[wez]

Run watchman --persistent --server-encoding=json log-level debug in one window, then in another, touch a .css file. Watchman should assess the trigger for your css and try to invoke celerity_mapper.php.

The triggers happen on file changes as they are noticed; it doesn't talk to git to see if the file is different

[nmalcolm]

Output: http://pastebin.com/d8QeTWej

The triggers happen on file changes as they are noticed; it doesn't talk to git to see if the file is different

I'm aware; git status shows that the .css files are modified but once they have been it should also show that ./src/__celerity_resource_map__.php has been modified too.

[wez]

Have to dash, but wanted to quickly respond: the output in your paste shows that watchman is trying to execute this:

"./scripts/celerity_mapper.php ./webroot" "changedfile.css"

We use a driver script for the command; you could do something like:

#!/bin/sh
exec ./scripts/celerity_mapper.php ./webroot $*

and then register that as your trigger

[nmalcolm]

The command which needs to be executed is ./scripts/celerity_mapper.php ./webroot. Is there a way to omit the argument which watchman adds?

This is the command I'm using to create the trigger.

watchman -- trigger /var/www/phabricator generatestatic '*.css' -- "./scripts/celerity_mapper.php ./webroot"

[wez]

If you don't want to pass the changed files to celerity_mapper.php, you should use a script like this:

#!/bin/sh
exec ./scripts/celerity_mapper.php ./webroot

Then

watchman -- trigger /var/www/phabricator generatestatic '*.css' -- './scripts/run-celerity-mapper.sh'

otherwise, change your quoting so that it runs the right thing:

watchman -- trigger /var/www/phabricator generatestatic '*.css' -- ./scripts/celerity_mapper.php ./webroot

We don't currently have a way to tell the trigger dispatcher to not pass the changed filenames, but do want to add that functionality.

[nmalcolm]

I had tried that originally but this is the only debug output when I changed the CSS file:

{
    "version": "2.8.2",
    "log": "1381517326: tid=798742272 inotify read: returned 256.\n"
}
{
    "version": "2.8.2",
    "log": "1381517326: tid=798742272 inotify read: returned 192.\n"
}

It doesn't look like it's trying to execute celerity_mapper.php?

[wez]

I turned off BSER by default in the CLI, so I'm considering this good enough for now.
The future for this is a BSER implementation based on libphenom when I finally get a chance to push that diff.