spawn EXTBSY error #224
Comments
|
Still the same. It seems there is a lack of support from browserstack which is not great. |
|
It seems the logic in Nodejs changed a bit in the latest version(s). |
diff --git a/node_modules/browserstack-runner/lib/local.js b/node_modules/browserstack-runner/lib/local.js
index 15b147c..4f15a49 100644
--- a/node_modules/browserstack-runner/lib/local.js
+++ b/node_modules/browserstack-runner/lib/local.js
@@ -180,16 +180,16 @@ var Tunnel = function Tunnel(key, port, uniqueIdentifier, config, callback) {
}
logger.debug('Downloading BrowserStack Local to "%s"', localBinary);
- var file = fs.createWriteStream(localBinary);
+ var file = fs.createWriteStream(localBinary, {emitClose: true});
https.get('https://s3.amazonaws.com/browserStack/browserstack-local/BrowserStackLocal' + (windows ? '.exe' : '-' + process.platform + '-' + process.arch),
function(response) {
response.pipe(file);
response.on('end', function() {
- fs.chmodSync(localBinary, 0700);
- setTimeout(function() {
+ file.on('close', function () {
+ fs.chmodSync(localBinary, 0700);
tunnelLauncher();
- }, 100);
+ })
}).on('error', function(e) {
logger.info('Got error while downloading binary: ' + e.message);
throw new Error('Got error while downloading binary: ' + e.message); |
|
Getting this too. 😅 Does it work with older node versions or something? |
|
I tried applying @DanielRuf 's patch but I'm still getting the error. This is with node v12.16.2 and browserstack-runner 0.9.3 (with and without the patch) |
|
@DanielRuf Was there a particular version that worked for you? I found that deleting the BrowserLocal binary before running the tests helped. (though this seems a bit inefficient). |
|
We use browsertack-runner 0.9.2 and Node 14.7.0 |
|
Closing as there seems to be no further interest to resolve this. |
|
Hey, your statement on 2nd Aug mentions that the issue was resolved using the latest version of NodeJS, are you still facing any errors? |
|
@wati123321 it works with my own patch / changes.
No, not in the original project without the patch by me. |
|
I was able to resolve this by deleting package-lock.json prior to running You can see it failing here with the above error. But then passing here when i add the I'm still curious as to why removing package-lock should work. Since browserstack-runner works on Mac locally perhaps some post install operations of the dependencies install something architecture specific. |
Krinkle
added a commit
to Krinkle/browserstack-runner
that referenced
this issue
Apr 11, 2021
Currently after installing browserstack-runner you can run one test.
After that, the command is broken. There are numerous symptoms
from this:
* BrowserStackLocal gets re-downloaded every single time.
* an ETXTBSY error appears because the previous file is still busy.
Here is what happens on later runs:
* `fs.exists(localBinary)` finds the binary.
* `runTunnelCmd(['-version'])` gets the following output:
```
$ node_modules/browserstack-runner/lib/BrowserStackLocal -version
Sun Apr 11 2021 20:59:41 GMT+0000 (UTC) -- BrowserStackLocal v8.1
Sun Apr 11 2021 20:59:41 GMT+0000 (UTC) -- Container runtime environment detected
Sun Apr 11 2021 20:59:41 GMT+0000 (UTC) -- Attaching services to public interface
BrowserStack Local version 8.1
```
* Only the first line of data is checked by `subProcess.stdout.on('data')`.
* The line does not match `/version\s+(\d)/`. It reports: `Tunnel binary: found version null`.
* The script invokes `callbackOnce()` and will try to kill the process. This may succeed, but it is not immediate as there are additional output lines still in the data buffer which must be processed first, which is not possible since we are still indirectly in the call stack of the first `data` stdout callback.
* The re-download begins, but the operating system does not permit writing to a currently executing binary, since it will not shutdown until a few milliseconds later.
* We fail with `Error: ETXTBSY: text file is busy`.
All of this happens only because `-version` is interpreted as both `-v` for verbose and `--version` at the same time, the verbose output comes first and does not match the regex. Changing it to `--version` solves the problem.
This code should also be changed so that it actually waits for this subprocess to exit. Perhaps falling back to unlinking the file if we can't close it so that at least the redownload will work. But, that is another issue and will not be a problem in most cases.
Fixes browserstack#224.
Krinkle
added a commit
to qunitjs/browserstack-runner
that referenced
this issue
Apr 11, 2021
Currently after installing browserstack-runner you can run one test.
After that, the command is broken. There are numerous symptoms
from this:
* BrowserStackLocal gets re-downloaded every single time.
* an ETXTBSY error appears because the previous file is still busy.
Here is what happens on later runs:
* `fs.exists(localBinary)` finds the binary.
* `runTunnelCmd(['-version'])` gets the following output:
```
$ node_modules/browserstack-runner/lib/BrowserStackLocal -version
Sun Apr 11 2021 20:59:41 GMT+0000 (UTC) -- BrowserStackLocal v8.1
Sun Apr 11 2021 20:59:41 GMT+0000 (UTC) -- Container runtime environment detected
Sun Apr 11 2021 20:59:41 GMT+0000 (UTC) -- Attaching services to public interface
BrowserStack Local version 8.1
```
* Only the first line of data is checked by `subProcess.stdout.on('data')`.
* The line does not match `/version\s+(\d)/`. It reports: `Tunnel binary: found version null`.
* The script invokes `callbackOnce()` and will try to kill the process. This may succeed, but it is not immediate as there are additional output lines still in the data buffer which must be processed first, which is not possible since we are still indirectly in the call stack of the first `data` stdout callback.
* The re-download begins, but the operating system does not permit writing to a currently executing binary, since it will not shutdown until a few milliseconds later.
* We fail with `Error: ETXTBSY: text file is busy`.
All of this happens only because `-version` is interpreted as both `-v` for verbose and `--version` at the same time, the verbose output comes first and does not match the regex. Changing it to `--version` solves the problem.
This code should also be changed so that it actually waits for this subprocess to exit. Perhaps falling back to unlinking the file if we can't close it so that at least the redownload will work. But, that is another issue and will not be a problem in most cases.
Fixes browserstack#224.
Ref browserstack#242.
francisf
pushed a commit
that referenced
this issue
Apr 19, 2021
Currently after installing browserstack-runner you can run one test.
After that, the command is broken. There are numerous symptoms
from this:
* BrowserStackLocal gets re-downloaded every single time.
* an ETXTBSY error appears because the previous file is still busy.
Here is what happens on later runs:
* `fs.exists(localBinary)` finds the binary.
* `runTunnelCmd(['-version'])` gets the following output:
```
$ node_modules/browserstack-runner/lib/BrowserStackLocal -version
Sun Apr 11 2021 20:59:41 GMT+0000 (UTC) -- BrowserStackLocal v8.1
Sun Apr 11 2021 20:59:41 GMT+0000 (UTC) -- Container runtime environment detected
Sun Apr 11 2021 20:59:41 GMT+0000 (UTC) -- Attaching services to public interface
BrowserStack Local version 8.1
```
* Only the first line of data is checked by `subProcess.stdout.on('data')`.
* The line does not match `/version\s+(\d)/`. It reports: `Tunnel binary: found version null`.
* The script invokes `callbackOnce()` and will try to kill the process. This may succeed, but it is not immediate as there are additional output lines still in the data buffer which must be processed first, which is not possible since we are still indirectly in the call stack of the first `data` stdout callback.
* The re-download begins, but the operating system does not permit writing to a currently executing binary, since it will not shutdown until a few milliseconds later.
* We fail with `Error: ETXTBSY: text file is busy`.
All of this happens only because `-version` is interpreted as both `-v` for verbose and `--version` at the same time, the verbose output comes first and does not match the regex. Changing it to `--version` solves the problem.
This code should also be changed so that it actually waits for this subprocess to exit. Perhaps falling back to unlinking the file if we can't close it so that at least the redownload will work. But, that is another issue and will not be a problem in most cases.
Fixes #224.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We are getting the following error:
Related: browserstack/browserstack-local-nodejs#19
The text was updated successfully, but these errors were encountered: