Titanium JIRA Archive
Appcelerator Daemon (DAEMON)

[DAEMON-233] appcd-fswatcher: EACESS error when starting appcd-plugin-android

GitHub Issuen/a
Resolution Date2018-03-09T22:34:06.000+0000
Affected Version/sAppc Daemon 1.1.0
Fix Version/sAppc Daemon 1.1.0
ReporterEwan Harris
AssigneeChris Barber



When calling appcd exec /android/latest/info on master of appc-daemon, the plugin fails to start with, Failed to activate plugin (code 6), I've tracked this back through the rabbit hole and there seems to be a few things that are at play here. I trimmed the plugin down to only do NDK detection to hopefully make the logs a little easier to read (although I had to bump the buffer to 2.5k from 1k) * Walking through the changes in appcd-detect seem to show [this commit](https://github.com/appcelerator/appc-daemon/commit/829d533762fbd03e52b0e9da88276992b5da6a30#diff-1174f97bf7dc72538ff82fe34bbc5c65) as being the commit that made this start failing * androidlib lists [/opt](https://github.com/appcelerator/androidlib/blob/82cfefac30aa5bb92fc5b7865a1ccbcf27c4eacd/src/ndk.js#L17) as a place to scan for the NDKs, this doesn't seem to exist on my system so when we do a real on this path [https://github.com/appcelerator/appc-daemon/blob/93841cf2c52a82151f061a1f1ea38317efbb8ecf/packages/appcd-detect/src/detect-engine.js#L228] it becomes / * From the logs in the attached appcd dump it then seems that the detect engine then starts to watch all subdirectories of / (timestamp is around 2018-02-12T17:13:39.535Z) * Some of the directories underneath the root throw an EACCESS on fs.watch, I've logged this in the logs around timestamp 2018-02-12T17:13:39.554Z, which cause the plugin to start I believe we should be handling EACCESS errors in the fswatcher




  1. Chris Barber 2018-03-01

    PR: https://github.com/appcelerator/appc-daemon/pull/289
  2. Ewan Harris 2018-03-02

    [~cbarber] This PR deals with the access permissions I was seeing but https://github.com/appcelerator/appc-daemon/commit/829d533762fbd03e52b0e9da88276992b5da6a30#diff-1174f97bf7dc72538ff82fe34bbc5c65 is still causing something funky. Calling the android info endpoint takes a while and watches a ton of stuff, see the below output of appcd exec /appcd/status/fs after calling android info.
         "nodes": 51,
         "fswatchers": 47,
         "watchers": 27
         "fswatchers": 3607,
         "nodes": 5491,
         "watchers": 290
    On OSX calling appcd exec /android/latest/info takes around 44 seconds for me on 1.1.0, vs 2 seconds on 1.0.1
  3. Chris Barber 2018-03-09

    To test, run gulp coverage from the packages/appcd-fswatcher directory on all platforms. Then on Linux and macOS, run sudo gulp coverage.

JSON Source