Fresh install of Meteor 0.5.0 on Windows Vista. I don't get the basic examples working. No success after creating the empty'ish hello app either. The shell is running as admin. Meteor recognises that I changed a source file, but then nothing. It doesn't matter where in the filesystem i try this. Always getting
Exited with code: -1073741819:
eg
C:\Users\jawford\Meteor Apps\Examples>meteor create starter3
starter3: created.
To run your new app:
cd starter3
meteor
C:\Users\jawford\Meteor Apps\Examples>cd starter3
C:\Users\jawford\Meteor Apps\Examples\starter3>meteor
[[[[[ C:\Users\jawford\Meteor Apps\Examples\starter3 ]]]]]
Running on: http://localhost:3000/
Exited with code: -1073741819
Exited with code: -1073741819
Exited with code: -1073741819
Your application is crashing. Waiting for file change.
=> Modified -- restarting.
Exited with code: -1073741819
Exited with code: -1073741819
Exited with code: -1073741819
Your application is crashing. Waiting for file change.
^CTerminate batch job (Y/N)? y
C:\Users\jawford\Meteor Apps\Examples\starter3>
If you run into this problem using Windows 8, you will need to change compatibility mode for the node executable.
Go to the folder where you installed Meteor
Open properties for bin/node.exe
Set compatibility mode for Windows 7
You should now be able to start the application as you did earlier.
This has to do with Fibers not loading correctly. You can attempt to run app/meteor/meteor.js with bin/node, both are in the Meteor directory in Program Files. This could maybe give you more details why it is crashing. It might also be handy to run the tests in the lib/node_modules/fibers folder which might point out why Fibers is misbehaving.
The exit code -1073741819 corresponds to C0000005 which indicates an access violation.
Many users find that setting compatibility mode to "Windows 7" solves that problem, but it doesn't always and there is some evidence that it also occurs on Windows 7.
Investigating a later issue on win Meteor 0.5.9, I discovered a problem with fibers on windows that may explain this issue, and I have a tentative fix.
Please see: https://github.com/TomWij/meteor/issues/66#issuecomment-15994548 for further details.
Related
The cloudrun debug in cloud shell was working. It is no longer working for me with the following output.
I have 1) rebooted the VM and 2) I have tried another project that was also working previously.
I suspect something has changed in my environment
Starting to debug the app using configuration 'Cloud Run: Run/Debug
Locally' from .vscode/launch.json... To view more detailed logs, go to
Output channel : "Cloud Run: Run/Debug Locally - Detailed" Dependency
check started Dependency check succeeded Unpausing minikube flag needs
an argument: --status-check See 'skaffold debug --help' for usage.
Exited with code 127. Cleaning up... Finished clean up.
This bug was introduced in the v1.17.1 release of Cloud Code for VS Code, due to a change in v1.37.0 of Skaffold related to the --status-check parameter. This bug was addressed in v1.17.2 of Cloud Code for VS Code, and upgrading to this version (or later) should fix this issue.
I've recently been developing an app, and noticed a few days ago I updated R to 4.1.2. After making some changes to the app, I used the Publish button to deploy to shinyapps.io. The deployment console threw the following error and failed:
Error: Unhandled Exception: Child Task 1045191965 failed: Error building image: R version 4.1.2 currently unavailable
Execution halted
Now, I've deployed many times previously, and this was the first deployment since the update to R. I haven't included any code because my app.R is over 1500 lines and it really didn't seem to be related to any of thee changes I made. I was wondering if anyone could help me figure out whether this error is referring to my system or the server I am deploying to. I expect I may have to roll back to the pre-update snapshot and try again, but I'd like to avoid doing that if the problem lies somewhere else.
Rstudio is Version 1.4.1103
Operating system:
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal
Thanks in advance!
After checking with shinapps.io support, they informed me their server has not been updated to 4.1.2 and to downgrade until they are able to make the upgrade. They were not able to provide an ETA on that. Thanks to the support staff there!
I am trying to deploy my application built in ASP.Net 4.6.1. So I am using HWC Buildpack.
Below is my manifest.yml
---
applications:
- name: DRSN
random-route: true
memory: 128M
buildpack:
https://github.com/cloudfoundry/hwc-buildpack.git
env:
DOTNET_CLI_TELEMETRY_OPTOUT: 1
DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
The error that I am receiving is below.
Waiting for API to complete processing files...
Staging app and tracing logs...
Cell 0f7012eb-9e32-4fdf-ba92-85aee4639139 creating container for instance 34107c3c-1acb-4aa5-b435-b06516abcfcb
Cell 0f7012eb-9e32-4fdf-ba92-85aee4639139 successfully created container for instance 34107c3c-1acb-4aa5-b435-b06516abcfcb
Downloading app package...
Downloading build artifacts cache...
Downloaded build artifacts cache (231B)
Downloaded app package (19.5M)
Failed to compile droplet: Failed to compile droplet: fork/exec /tmp/buildpackdownloads/6c6dca8d638ac0d145d6581f9eb9a96a/bin/compile: permission denied
Exit status 223
Cell 0f7012eb-9e32-4fdf-ba92-85aee4639139 stopping instance 34107c3c-1acb-4aa5-b435-b06516abcfcb
Cell 0f7012eb-9e32-4fdf-ba92-85aee4639139 destroying container for instance 34107c3c-1acb-4aa5-b435-b06516abcfcb
Error staging application: App staging failed in the buildpack compile phase
Can anyone help me resolve this issue? Am I not correct in my manifest.yml? Or is it something else?
I believe that the problem is that you're telling the system to use the HWC buildpack, but at the same time you're not setting the Windows stack (at least based on what info I can see). That means it's going to default to the Linux stack, which I believe is why you're seeing the fork/exec /tmp/buildpackdownloads/... error.
Try adding stack: windows to your manifest.yml or -s windows to your cf push command (for future reference, when you need help always include the full cf push command you're running).
PS: you shouldn't use https://github.com/cloudfoundry/hwc-buildpack.git that is telling the system to grab the master branch in whatever state it's currently in. That's a.) not reproducible and b.) not guaranteed to be in a working state. You should either use the platform provided buildpack names (from cf buildpacks) or append #<branch_or_tag> to the end of the URL so it picks a specific branch. All CF Buildpacks have tags for each release. It's strongly recommended you use a tagged release.
I am using Meteor 1.4.3.2 on a windows7 dev environment.
A Meteor application I have developed has been great for 6+ months but I have caused a problem by removing modules and apparently something I should not have.
Something outside the application folders (sym-link pointing into \AppData\Local.meteor.. somewhere) is missing/wrong, I think.
All other projects are fine, except this one.
All of my backup copies for this project are failing now too, including fresh clone from repo.
No 'meteor' commands will in this project, or it's backup copies, so 'meteor reset' is not an option.
The error is:
C:\Users\muser\iNotice>meteor
C:\Users\muser\AppData\Local\.meteor\packages\meteor-tool\1.4.3_2\mt-os.windows.
x86_32\dev_bundle\lib\node_modules\meteor-promise\promise_server.js:190
throw error;
^
Error: EPERM: operation not permitted, unlink 'C:\Users\muser\iNotice\.meteor\lo
cal\dev_bundle'
at Error (native)
at Object.fs.unlinkSync (fs.js:932:18)
at exports.makeLink (C:\tools\cli\dev-bundle-links.js:20:8)
at [object Object]._.extend.ensureDevBundleLink (C:\tools\project-context.js
:1476:7)
at [object Object]._.extend._readFile (C:\tools\project-context.js:1410:10)
at new exports.ReleaseFile (C:\tools\project-context.js:1360:8)
at C:\tools\cli\main.js:898:22
Any suggestions on best approach to fix the application?
Thanks very much for your time and expertise.
Pick one of the following:
You can delete the content of your .meteor/local folder (repopulated next time you run > meteor)
Or call meteor as an admin
Or remove the read-only access on the dev_bundle folder (but Windows sets it back to read-only from time to time)
Thanks #n3squik!
Here are the actions I took which fixed my problem.
Remove folders:
C:\Users\muser\testApp\.meteor\local\dev_bundle*\*
C:\Users\muser\AppData\Local\.meteor\packages\meteor-tool\1.4.0-1\*
Ran:
C:\Users\muser\testApp> meteor run
The application started up and all seems good.
Thanks again Stack.
Made complete clean install of Centos OpenVZ server running 7 minimal 64bit, 2 'slices' of VPS with 2Gb ram, 2 cpus, 2gb swap etc,
Installed virtualmin/webmin that is all, only configuration undertaken in iptables firewall,
No other apps or software installed, only yum update ran,
Then downloaded meteor using curl link,
followed instructions to letter and in /root/ ran meteor create command,
this created myapp then cd myapp into /myapp directory, ran meteor,
repeatedly crashes with this error message, Why??
Have searched web for answers and no one seems to know, this is a recurrent problem with meteor since 2013 and even before if you research web so why hasn't it been fixed? And why is it so difficult to get the software to run 'out of the box' its whole premise is its user friendliness and ability to save time, I would love to be able to use it and have signed up to some basic training so really need to get this working! It should not be this difficult! Especially when just running the tutorial app...
Thanks for any help and advice you can give,
[root#server myapp]# ls
myapp.css myapp.html myapp.js
[root#server myapp]# meteor
[[[[[ ~/myapp ]]]]]
=> Started proxy.
=> Started MongoDB.
/root/.meteor/packages/meteor-tool/.1.1.10.ki0ccv++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/fibers/future.js:245
throw(ex);
^
Error: spawn ENOMEM
at errnoException (child_process.js:1011:11)
at ChildProcess.spawn (child_process.js:958:11)
at Object.exports.spawn (child_process.js:746:9)
at [object Object]._.extend._spawn (/tools/runners/run-app.js:255:31)
at [object Object]._.extend.start (/tools/runners/run-app.js:85:22)
at [object Object]._.extend._runOnce (/tools/runners/run-app.js:716:16)
at [object Object]._.extend._fiber (/tools/runners/run-app.js:858:28)
at /tools/runners/run-app.js:396:12
[root#server myapp]#
top image not using any ram or resources
Stack Enomem is due to interaction between node.js and OpenVZ, I would highly recommend using KVM instead with CENTOS7 upgraded (at cost of only 2 dollars) and this memory problem went away,
For rest of problems with accessing web dev server see advice given to me on meteor forum,
https://forums.meteor.com/t/first-attempt-at-tutorial-app-crashes-on-execution/13920?u=tombranley