facebook / react-native

A framework for building native applications using React
https://reactnative.dev
MIT License
118.46k stars 24.25k forks source link

Windows & Android: react native server crashes very often #9136

Closed pvllnspk closed 7 years ago

pvllnspk commented 8 years ago
 ERROR  EPERM: operation not permitted, lstat '...\.idea\workspace.xml___jb_old___'
{"errno":-4048,"code":"EPERM","syscall":"lstat","path":"...\.idea\\workspace.xml___jb_old___"}
Error: EPERM: operation not permitted, lstat 'app\.idea\workspace.xml___jb_old___'
    at Error (native)

After that I should again do:

npm start

How to resolve this quite annoying problem? Thanks

llioor commented 7 years ago

I already installed Android sdk. With a clean project I can run the app on my avd emulator. The problem starts only when I install the fbsdk and setting it up.

llioor commented 7 years ago

Solution found: http://stackoverflow.com/a/43217182/2862728

rockynox commented 7 years ago

I have a feeling that it's a conflict between the server and the build android which try to access same files. Indeed in Webstorm they are both launch simultaneously and since I installed new react-module (react-native-fcm/react-native-fabric) it creates this permission conflict.

Two solution worked for me :

- gradlew clean (with "cd android && gradlew clean" as @llioor said)
- Then normal run config (start and run-android at the same time)

or

- react-native start
*Wait for it to be completely up*
- react-native run-android 
43081j commented 7 years ago

This still happens for me...

> react-native --version
react-native-cli: 2.0.1
react-native: 0.43.3

In procmon, I see a huge amount of file operations with status "BUFFER OVERFLOW", could be related? I forgot buffer overflows are just buffer length checks...

Seems when anything that isn't the packager tries to access the same files, the packager throws a fit. It won't run again until I remove my node_modules and re-install (yarn). So my guess is something bad going on with open file handles, etc...

Also do note, I use vim and CLI, so you can rule out any editor/android studio/etc I guess.

Almost always, too, the lstat errors are on .git paths and node_modules/.bin paths.

This issue really shouldn't be closed, I suggest you re-open it @ericnakagawa.

Dashue commented 7 years ago

After running the packager manually outside of vscode, and attaching to it for debugging, everything is way faster and I no longer hit any issues. Give it a try?

On 17 Apr 2017 11:52 a.m., "James Garbutt" notifications@github.com wrote:

This still happens for me...

react-native --version react-native-cli: 2.0.1 react-native: 0.43.3

In procmon, I see a huge amount of file operations with status "BUFFER OVERFLOW", could be related?

Seems when anything that isn't the packager tries to access the same files, the packager throws a fit. It won't run again until I remove my node_modules and re-install (yarn). So my guess is something bad going on with open file handles, etc...

Almost always, too, the lstat errors are on .git paths and node_modules/.bin paths.

This issue really shouldn't be closed, I suggest you re-open it @ericnakagawa https://github.com/ericnakagawa.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/facebook/react-native/issues/9136#issuecomment-294449462, or mute the thread https://github.com/notifications/unsubscribe-auth/AAc6vULEz8sNdyI4XVRIfuONNX4UZNH7ks5rw0RUgaJpZM4JZooz .

43081j commented 7 years ago

Right now I'm pretty much running it all outside any editor and have always been:

Result is an unknown lstat error (code -4094).

I've stepped through the packager and broke on the exception, but its literally just an lstat error, no useful information.

Re-running the packager after it has errored results in the same error (sometimes on a different path). So at this point it no longer functions at all.

The only solution I found is to trash the entire node_modules directory and re-install it all, presumably because the mass of file handles it has open get freed... (its monitoring node_modules by the looks of it, thats potentially a huge tree).

Also sounds like the solution way up above, of running a clean build in android studio, is solving the problem the same way my node_modules deletion is? Basically if you delete a load of files the packager was watching, it works. Sounds like too many watches to me...

codebymikey commented 7 years ago

Expanding on @withparadox2 solution:

This solved the issue for me on: react-native-cli: 2.0.1 react-native: 0.35.0

Create the following rn-cli.config.js file in your project's root directory containing something similar to this (change as you see fit):

let blacklist = require('react-native/packager/blacklist');
let config = {
    getBlacklistRE(platform) {
        return blacklist(platform, [
            // Ignore local `.sample.js` files.
            /.*\.sample\.js$/,

            // Ignore IntelliJ directories
            /.*\.idea\/.*/,
            // ignore git directories
            /.*\.git\/.*/,
            // Ignore android directories
            /.*\/app\/build\/.*/,

            // Add more regexes here for paths which should be blacklisted from the packager.
        ]);
    }
};
module.exports = config;
dcp12345678 commented 7 years ago

I had this problem as well after upgrading to react-native 0.43.4 using react-native-git-upgrade. I use Visual Studio Code on Windows 7 and run on the Android Emulator that comes with Android Studio. Here is the solution that worked for me:

  1. Close any running instances of android emulator and react packager.
  2. Under /android, remove the build folder and all its contents.
  3. Under /android/app, remove the build folder and all its contents
  4. Go back to your project folder and do 'react-native run-android', and with any luck, your project will run.
pierre-H commented 7 years ago

I have the same problem.

I use VS Code 1.11.2, Windows 7 and create-react-native-app. The problem started since I did git init.

Any solution ? @ericnakagawa this issue should be re-opened

llioor commented 7 years ago

@pierre-H check my solution up.

pierre-H commented 7 years ago

@llioor There is no android folder with creact-react-native-app

llioor commented 7 years ago

@pierre-H If you are working with create native app so open issue on their git repo because it is not related to the same issue.. the current issue is realted to the "build" folder and you are not working with build folder until you are not "eject" from "create react native app".

If you want, go through these steps: https://facebook.github.io/react-native/docs/getting-started.html and if you have the same issue as mentioned in the first comment here so check my solution.

fgeorgsson commented 7 years ago

On every build I get the same problem. The packager crashes since it is watching files that are deleted or modified during build.

Typical error:

ERROR  ENOENT: no such file or directory, scandir 'C:\projects\foo\android\app\build\intermediates\res\merged\bar\release\values-xlarge-v4'
{"errno":-4058,"code":"ENOENT","syscall":"scandir","path":"C:\\projects\\foo\\android\\app\\build\\intermediates\\res\\merged\\bar\\release\\values-xlarge-v4"}
Error: ENOENT: no such file or directory, scandir 'C:\projects\foo\android\app\build\intermediates\res\merged\bar\release\values-xlarge-v4'

The actual file it crashes on varies, but always in the android\app\build folder.

I tried the suggestion to add a rn-cli.config.js file like earlier in the thread, specifically telling it to ignore android/app, but that makes no difference.

Windows 10 react-native-cli: 2.0.1 react-native: 0.43.4

llioor commented 7 years ago

@pcguru did you read all comments in this post? Solution found: http://stackoverflow.com/a/43217182/2862728

fgeorgsson commented 7 years ago

We're not using react-native-fbsdk.

The packager shouldn't be monitoring the build folder.

Venryx commented 7 years ago

@pcguru Newer versions of react-native apparently use a different signature for blacklisting -- you're supposed to no longer include the "platform" parameter.

So @codebymikey's solution here should work, except instead of:

[...]
    getBlacklistRE(platform) {
        return blacklist(platform, [
            [...]
        ]);
    }
[...]

It should now be:

[...]
    getBlacklistRE() {
        return blacklist([
            [...]
        ]);
    }
[...]

For reference, see here and here.

For me, with:
react-native-cli: 2.0.1
react-native: 0.42.0-rc.3

This finally worked! Solved the agonizing, horrible process of deleting the entire build folder every time I wanted to change anything in the Java code.

Really, the blacklist function should throw an error or something, if it has an extra parameter... would save some headaches for people following outdated blacklisting code. (it currently just fails completely silently)

EDIT: Actually, this didn't solve it. See below for a working solution.

Venryx commented 7 years ago

Hmmm. I perhaps spoke too soon. While the above may have helped (hard to tell -- I don't want to replicate the old state to confirm), I then found I was still getting errors a couple builds later.

However, I believe I've fixed it fully now, by using watchman, as recommended by @chardlau here: https://github.com/facebook/react-native/issues/9136#issuecomment-236767931

However, the link he gave is outdated. The latest version can be obtained here: https://facebook.github.io/watchman/docs/install.html

Also note that, in my project, I had some pretty deep issues when switching over to watchman at first. I've been working on the fixes for these for the last 5 hours, but I've finally got them fixed, and the project building again. (it required me to make some changes in the node_modules)

I don't really have time to go over the details of the problems I had switching to watchman (unless someone else actually hits the same problem, anyway), but I've summarized some basic parts of it here: https://github.com/Venryx/LucidLink/blob/master/Troubleshooting.md

EDIT

I've since found the root cause of the watchman issues: the paths were not being normalized in the jest-haste-map module, causing duplicate entries, and "misses" when calling hasteMap.exists().

I reported the issue here, along with the solution: https://github.com/facebook/jest/issues/3752

So in other words, to solve the "ERROR EPERM: operation not permitted, lstat" problem: 1) Install watchman, and add it to your path: https://facebook.github.io/watchman/docs/install.html 2) Make the changes to the jest-haste-map file, as seen here (if you encounter the duplicate-module warnings and module-not-found errors): https://github.com/facebook/jest/issues/3752 3) [edit] Oh, you might also need this, in a ".watchmanconfig" file in your project root. I don't seem to need it in mine, but it's worth mentioning in case it's needed in other people's cases.

{
    "ignore_dirs": [
        "android"
    ]
}

Also, note that when running "react-native start" to start the packager, in some cases it might be necessary to add the "--resetCache" flag. I've had some issues in my debugging process where cached files were kept, causing my latest "react-native start" to not recreate all the files. (either causing problems, or hiding problems)

Venryx commented 7 years ago

I've found a second solution.

1) Move your index.android.js entry file into the src folder. 2) Update your android/app/build.gradle file:

project.ext.react = [
    // the entry file for bundle generation
-    entryFile: "index.android.js",
+    entryFile: "src/index.android.js",
    extraPackagerArgs: ["--sourcemap-output", file("$buildDir/outputs/index.android.js.map")],
];

3) Update your android\app\src\main\java\v\<project name>\MainApplication.java file:

    private final ReactNativeHost mReactNativeHost = new ReactNativeHost(this) {
        @Override
        protected String getJSMainModuleName() {
-            return "index.android";
+            return "src/index.android";
        }

4) Create an rn-cli.config.js file in your project's root, with these contents:

var path = require("path");
let config = {
    getProjectRoots() {
        return [path.resolve("node_modules"), path.resolve("src")];
    },
};
module.exports = config;

What this does is it removes the need for the blacklist -- it just doesn't even start processing anything other than what's in "src" and "node_modules". This means, when you build your project, the file-changes in "android" are not even on the radar. (Of course, if you make Java/Android changes within the "node_modules" folder and build them, the packager may crash. But this is not very common, so it's okay.)

So why does this work, but not the "ignore list"? I think it's because the file-watcher system does some operations even on "ignored" paths -- it doesn't do the full processing, but still calls "lstat" on the files. (In my project, paths which were ignored, and confirmed as such with custom code in various places in react-native's js files, still showed up in errors for an "lstat" operation in the packager process -- unfortunately, the stack trace just said "Error (native)" or something. Of course, the ignore-not-fully-ignoring might also just be a side-effect of the non-normalized-paths-causing-duplicate-entries issue mentioned in my previous post.)

So anyway, if the above solution of using watchman doesn't work, you can try this one as well. (I'm currently going with the watchman solution, however, since I've read that it's somewhat faster)

Phew! Anyway, hope I can finally close the book on this one...

Aroniez commented 7 years ago

Still same problem in Win 7 with the following versions react-native-cli: 2.0.1 react-native: 0.44.2

ashikjs commented 7 years ago

I Gave a Answer hare And I Got Solution from this Link

facosta0787 commented 7 years ago

Hello, I had the same problem on windows 10 , I could fix it following the next steps: Run one by one 1. go to folder android into your project and run gradlew clean.

2. return to root folder of your project and run react-native start. wait until React Packager is ready and says: "loading dependency graph, done".

3. now run react-native run-android.

If all is right you project should run in your Emulator whitout problems.

I hope works for you as It works for me.

hiteshsahu commented 7 years ago

Turned off Atom (editor) and Android Studio and tried again, Worked like a charm. Probably Android Studio indexing is interfering with npm.

mallelapavank commented 6 years ago

@hiteshsahu This worked in my case. I closed both Android Studio and Atom, then ran react-native run-android. Build was successful with no errors

Venryx commented 6 years ago

I've written a new Stack Overflow answer which sums up and extends a bit on the solution(s) presented above: https://stackoverflow.com/a/47420765/2441655

It doesn't require the developer to close the react-native packager or Android Studio, or call "gradlew clean"; which is nice, since those workarounds are annoying and eat away at your sanity.

My earlier posts (a couple pages up) are less clear because at the time I didn't understand the distinction between the two issues. (That, and there was a third issue in the "jest" module which made one of those two issues much harder to diagnose/debug -- the third issue is fixed now if you're using the latest versions, so doesn't need to be worked around anymore)

ddaeschler commented 6 years ago

This is still happening on RN 0.45.1 (at least on windows), and from all the comments it looks like a race condition against the filesystem. I think if lstat() fails and the file doesn't exist, it should simply not be considered an error.

These kinds of problems are really common when dealing with a filesystem outside of the control of the application. Almost nothing should be assumed about the filesystem structure from one second to the next.

Can I help somehow? Is there someone still working on a fix for this?

fatfatson commented 6 years ago

https://facebook.github.io/watchman/docs/config.html

On Linux systems, ignore_dirs is respected at the OS level; the kernel simply will not tell watchman about changes to ignored dirs. macOS and Windows have limited or no support for this, so watchman needs to process and ignore this class of change.

i think that's why .watchmanconfig.ignore_dirs=["android"] not work!

fatfatson commented 6 years ago

now the rn-cli.config.js become these:

let blacklist = require('metro-bundler/src/blacklist');

let config = {
    getBlacklistRE() {
        return blacklist([
            // Ignore local `.sample.js` files.
            /.*\.sample\.js$/,

            // Ignore IntelliJ directories
            /.*\.idea\/.*/,
            // ignore git directories
            /.*\.git\/.*/,
            // Ignore android directories
            /.*\/app\/build\/.*/

            // Add more regexes here for paths which should be blacklisted from the packager.
        ]);
    }
};
module.exports = config;

i have tried in : win10 react-native-cli: 2.0.1 react-native: 0.50.4

now the dev server won't be interupted by "lstat err" due to the rebuild process of android app