I am using a fresh Linux install. I am trying to install Meteor. Using Ubuntu 12.04, Centos and Ubuntu 13.04. I installed Node.js, Meteor and Meteorite.
Error:
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Can't start mongod
MongoDB had an unspecified uncaught exception.
This can be caused by MongoDB being unable to write to a local database.
Check that you have permissions to write to .meteor/local. MongoDB does
not support filesystems like NFS that do not allow file locking.
I've tried:
Deleting .meteor/local/db/mongod.lock
Also I tried to change the permissions for the whole project with chmod.
Do you recommend any Ubuntu distribution?
Thanks in advance.
I have run in this problem before (after meteor update or abnormal meteor termination) and these solutions worked for me before.
Restart your machine.
Delete the file .meteor/local/db/mongod.lock and run meteor again.
Execute meteor reset and start again, but this command will erase your database.
Hope it helps.
It some time depends on your locale settings.
Meteor reset and delete mongod.lock didn't help in my case.
I've fixed it by running
export LC_ALL=C
you can add this line to
sudo vim /usr/local/bin/meteor
All I had to do was run "killall mongod" in the terminal. After that it worked again. I believe it may have cleared parts of the database though.
For me a combination of the suggestions worked out. The answer that has gotten 2 down votes! and this one from another page.
sudo vim /usr/local/bin/meteor
export LC_ALL="en_US.UTF-8"
then make sure which port your mongodb is running at by issuing the following:
meteor mongo
You will get a response like this:
connecting to: 127.0.0.1:3001/meteor
now that you know the port on which the mongo is configured, add the following to the same file we have been editing:
export MONGO_URL=mongodb://127.0.0.1:3001/meteor
Now you are good to go. Of course "meteor reset" works but if you dont want to loose your data, stick with those two export lines.
I have found that setting MONGO_URL helps avoid issue
export MONGO_URL=mongodb://localhost:27017/your_db
If you're having this issue running Ubuntu inside Vagrant/VirtualBox, then the problem come from working in the synced vagrant folder.
The workaround is to initialize the .meteor directory in the home directory and to mount it in the synced folder. Assuming your meteor app is called MyApp and the /vagrant is the synced folder, here's how to do it:
cd ~
meteor create MyApp
cd MyApp
meteor
cd /vagrant/MyApp
sudo mount --bind ~/MyApp/.meteor/ .meteor
meteor
I had a similar issue. It was due to the fact that my project directory was part of my Dropbox and there was some conflicted files in the .meteor/local/db directory. Removing these solved the problem.
I encounter the same issue when my disk space ran low.
Freeing up some space in the disk fixed the problem for me.
I encountered this problem when I ran meteor in VMWare, ubuntu 14.04 guest on a Windows 7 host. The problem was that I was running meteor/mongo in a shared directory. When I used a non-shared directory (~/meteor/project) the problem disappeared.
Following the steps that #Oscar mentions further up should sort you out.
However in my case meteor reset wouldn't work, telling me this:
reset: Meteor is running.
This command does not work while Meteor is running your application. Exit the running Meteor development server.
For which I tracked the process down, like this:
$ ps aux | grep meteor --color=auto
which gave me this info:
$ myUser 71981 0.5 0.0 2849208 3644 ?? S Mon02pm 4:25.27 /Users/myUser/.meteor/packages/meteor-tool/.1.1.10.1b51q9m++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/dev_bundle/mongodb/bin/mongod --bind_ip 127.0.0.1 --smallfiles --port 2001 --dbpath /Users/jgt/Documents/Projects/todos/.meteor/local/db --oplogSize 8 --replSet meteor
As you can see I'm on Mac, but this works fine on any Unix based OS.
So then you only need to kill the process by it's id, like this:
$ kill -9 71981
And finally run again meteor reset
That's it, got it working now. Hope it helps.
One option is to wait until you have your app on a staging or production server, and then test it on an Android emulator provided by Android Studio or BlueStacks.
I am having this issue on WSL for Ubuntu on Windows. The only solution that worked for me was creating a remote mongodb with mLabs and ran the following
export MONGO_URL=mongodb://username:password#randomurl.mlab.com:port#/project
Recently I got the same case, which I run meteor on WSL for Ubuntu on windows 10. I resolved this case by updating WSL to version 2.
Note :
Make sure your Windows build is higher than the minimum WSL 2 requirements. And don't forget to set version 2 as WSL default version after updating.
wsl --set-version [linux_dist] 2
For windows 10, I moved all my Meteor projects in drive C. So far working.
Related
Ever since updating from WSL 1 to WSL 2 with the Windows 10 April 2020 update (and thereafter updating Ubuntu 18 to Ubuntu 20), I have not been able to get nodemon to hot reload when there are file changes in the project's directory. When I make any changes to .js files, there's no restarting of the server or output at the terminal:
I start my Node.js server with nodemon like this:
NODE_ENV=development DEBUG='knex:*' nodemon --verbose --inspect ./server.js"
And in case its useful, here is my server.js:
const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
console.log(`Server started and listening on port ${PORT}`);
});
I am not even sure how to troubleshoot this further to get more useful information about what's going on.
Root cause:
inotify is not fully supported in the 9P filesystem protocol on WSL2.
There are several github issues on the WSL project related to this, but perhaps the most relevant is #4739.
Possible Workarounds:
Try nodemon -L (a.k.a. --legacy-watch) as Simperfy suggested.
Try running from the default ext4 filesystem (e.g. mkdir -p $HOME/Projects/testserver). Note that a symlink to the Windows filesystem will still not work. As a bonus, the WSL ext4 filesystem will be much faster for file intensive operations like git.
You can still access the source from Windows editors and tools through \\wsl$\.
Use Visual Studio Code with the Remote-WSL extension to edit your source on the Windows filesystem. The easiest way to do this is by navigating in WSL to your project directory and running code ..
Visual Studio Code's WSL integration does trigger inotify for some reason.
Downgrade the session to WSL1 if you don't need any of the WSL2 features. I keep both WSL1 and WSL2 sessions around. The best way to do this is to create a backup of the session with wsl --export and wsl --import. You can switch the version of a WSL distro at any point with wsl --set-version.
I did test this on WSL1 with a sample project under the Windows filesystem, and editing via something as basic as notepad.exe under Windows still triggered nodemon to restart.
Longer answer:
nodemon worked "out of the box" for me on WSL2 on the root (/) ext4 mount (e.g. $HOME/src/testserver).
It also worked correctly when I tried it under the default /mnt/c mount that WSL/WSL2 creates. Of course, /mnt/c is much slower under WSL2. Edit - It turns out that I was using Visual Studio Code when I attempted this. Editing from other Windows apps on the Windows filesystem did not trigger nodemon to restart.
But looking at the first line of your screenshot, I see that you are running this from /c/Users/.... I'm thinking maybe you created this (perhaps CIFS) mount to try to work around the WSL2 performance issues - It's a common workaround.
I didn't set up a CIFS mount, but I was able to reproduce your problem by mounting with (substituting your Windows username):
mkdir $HOME/mnttest
sudo mount -t drvfs 'C:' $HOME/mnttest
cd $HOME/mnttest/Users/Raj/Projects/testserver
Running nodemon from this mount failed in the same manner that you describe -- Changes to the source did not trigger a restart.
However, running with nodemon -L on this mount did trigger a restart when source files were changed.
It also may be possible to fix the problem by mounting with different options, but I'm just not sure at this point. Edit - Seems unlikely, given the bug reports on this on Github.
Also, you may want to create some exports/backups of your WSL sessions. It's too late at this point (for your previous install), but you could have run wsl.exe --export to create a backup of the Ubuntu 18.04/WSL1 filesystem before upgrading. You can also change the version of a particular distribution with wsl.exe --set-version. This could give you some better "before/after" test comparisons.
I am using the WSL 2 and I solved the issue by adding the following env variable: CHOKIDAR_USEPOLLING=true.
This is how looks like my nodemon command:
CHOKIDAR_USEPOLLING=true nodemon index.js
Now you can keep WSL2 instead of moving your environment to WSL1.
I created a react application using create-react-app boilerplate, which seems to be very popular, hot reload some times updates when any of the files changes and some times not, seems like there is a minimum duration or something like that, I'm using Ubuntu, node version 7.0, the script in package.json is npm:'react-script start' what I am missing ?
When npm start doesn’t detect changes, below are the common troubleshooting steps provided in the create-react-app documentation - link.
While an app is running with npm start and updating code in the editor should possibly refresh the broswer with the updated code.
If this doesn’t happen, try one of the following workarounds:
If the project files are directly synced to your local system from a cloud storage like Dropbox or Google Drive and you're trying to run the app in them directly, try moving it out.
Due to Webpack bug, you may need to restart the watcher. If the watcher doesn’t detect the index.js and you’re referencing it by the folder name.
Safe write feature in editors like Vim and IntelliJ currently breaks the watcher. You will need to disable it.
Due to Webpack watcher bug, projects with path contains parentheses causes issue, try moving the project to a path without them. .
To allow more watchers in Linux and macOS, you might need to tweak system settings.
If the project runs inside a virtual machine such as (a Vagrant provisioned) VirtualBox, create an .env file in your project directory if it doesn’t exist, and add CHOKIDAR_USEPOLLING=true to it. This ensures that the next time you run npm start, the watcher uses the polling mode, as necessary inside a VM.
Could try increasing max_users_watches- link
More references:
Issue Tracker 1
Troubleshooting webpack
Issue Tracker 2 - Webpack polling
Try these:
Turn off safe write in your IDE
Increase max_user_watches
Your path should not have parentheses
as last resort try to use this as your env variable:
CHOKIDAR_USEPOLLING=true npm start
Sources:
https://github.com/facebookincubator/create-react-app/issues/659
https://github.com/facebookincubator/create-react-app/issues/1049#issuecomment-261731734
I was able to make this work using:
sudo npm start
run this command
sudo -i
echo 1048576 > /proc/sys/fs/inotify/max_user_watches
exit
try deleting the node_modules folder and reinstall
by using cmd npm install
worked for me ( ubuntu 18.04.3 LTS )
In unbuntu, i basically kill all the process running on port (for react app default is :3000).
List all the process running on port 3000.
lsof -i :3000
This command will show something like this.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
node 7429 yipl 19u IPv4 1081760 0t0 TCP localhost:3000->localhost:35762 (ESTABLISHED)
chrome 26448 yipl 177u IPv4 1080082 0t0 TCP localhost:35762->localhost:3000 (ESTABLISHED)
Now kill the process by PID.
kill -9 7429
kill -9 26488
Start your react app again.
Apparently hot module reloading only works out-of-the-box if you eject your app.
But if you haven't ejected your app, then you can follow these instructions to get it working.
Find the ReactDOM.render(...) at the top of your app, and add these lines below it:
ReactDOM.render(...);
if (module.hot) {
module.hot.accept('./App', () => {
// --- Copy-paste your usual ReactDOM.render(...) call here: --- //
ReactDOM.render(...);
});
}
The instructions linked above also show how to hot reload things outside of the component tree, such as redux reducers.
One additional case I just experience is when using multiple version of nodejs with NVM in parallel. Basically, I have two terminal windows, one run node 10.x, other on node 9.x, and Webpack watcher stops seeing change.
The solution is to bring both to the same node version
sudo npm start
i dont know more about linux, but it is probably due to firewall settings, as i have done the same in windows and there to start react dev server we need to give the access through firewall, so to do the same here we need to give it the admin permision(sudo in case of a ubuntu linux distribution).
If you start your app with a bunch of errors it seems to stop watching your files and thus will not detect your fixes to the broken files. It seems as if you need to initiate "start" with not too many/severe errors for the file watcher to work.
I am new to MEAN development which means I am new to MongoDB.
I have picked up Packt's book "MEAN Web Development" by Amos Haviv and I am running into issues right off the bat.
I have installed MongoDB no problems. I can run it just fine with "mongod" or by running the bin\mongod.exe command.
The problem is that the book has been telling me to do the following (and apparently the book is great so I doubt it would have gotten much acclaim if everyone got stumped like me so early on).
echo logpath = C:\mongodb\log\mongo.log > C:\mongodb\mongod.cfg
Cool, good, done. Config file is written and all is well.
Then it tells me to run this command
sc.exe create MongoDB binPath= "\"C:\mongodb\bin\mongod.exe\" --service --config= \"C:\mongodb\mongod.cfg\"" DisplayName= "MongoDB 2.6" start= "auto"
Again, runs fine. It gives me this message
[SC] CreateService Success
Then the author goes on to tell me that I should be able to run the following command.
net start MongoDB
Of which, mind you, I still do not really know what it's supposed to do. Is it the same as running
C:\>mongod
and
C:\mongodb\bin>mongod.exe
??
So, I try to run the command it suggests and I get the following:
System error 2 has occurred.
The system cannot find the file specified.
I have tried this solution already
MongoDB 3.0 Windows Service Start : System Error 2 has occured
But it doesn't seem to apply to me.
Please help. My knowledge of this stuff is quite limited (I am moving from mainly a PHP/JQuery background into this stuff and the initial setup is driving me crazy.
Any and all help is appreciate. Thanks all
B
EDIT - SOLUTION
Cannot start MongoDB as a service
This solution allowed me to fix my problem. I first had to uninstall the service that was supposedly successfully installed and then reinstall it using the command from this solution
mongod --logpath c:\mongodb\logs\mongo.log --dbpath c:\mongodb\data\db --directoryperdb --install
SOLUTION
Cannot start MongoDB as a service
This solution allowed me to fix my problem. I first had to uninstall the service that was supposedly successfully installed and then reinstall it using the command from this solution mongod --logpath c:\mongodb\logs\mongo.log --dbpath c:\mongodb\data\db --directoryperdb --install
Try running cmd as administrator it worked for me
I installed the stack on my laptop and it was working fine. Then I restarted my computer and tried to start mongo and it would not start.
the error message I get in the manager is
meanstack-3.0.6-1/mongodb/scripts/ctl.sh : mongodb could not be
started Stderr: child process exited abnormally
And when I try to start manually from a terminal I get an error saying data/db directory not found even though there is one.
I have already tried these steps with no luck:
1) Remove .lock file
sudo rm /var/lib/mongodb/mongod.lock
2) repair the mongodb
mongod –repair
3) start the mongodb
sudo service mongodb start
4) start the mongo client
just a tip: check your available free disc space, sometimes this kind of problems occurs because mongDb don't have enough space on the disc to run the server. if this is not working then manually check the log file Mongodb.log at 'yourPath\bitnami\meanstack-3.x.x-x\mongodb\log' hear you will sure find some proper clue.
Rename below file to anything
meanstack-3.0.6-1/mongodb/data/db/mongod.lock
restart mongodb from bitnami
note:-- mongodb installed in your system is different then installed through bitnami, they are using different ports, i.e. currently you have two instance of mongodb installed in your system.
I needed to install an old version of Mongo so I replaced all the files in the /bin folder with the old version and then I was getting the error "mongodb could not be started". I then deleted all the files under data/db and restarted using "./ctlscript.sh start mongodb" which worked.
I'm trying to get the cloud9 local server working on my Raspberry Pi(512mb model B, running raspbian).
I followed this installation guide:
http://www.slickstreamer.info/2013/02/how-to-install-cloud-9-on-raspberry-pi.html
After this installation everything appeared to be working properly, I can start the server with the following command:
~/cloud9/bin/cloud9.sh -l 0.0.0.0 -w ~/Documents/www/workspace/
when I start the server all the files in the workspace are displayed properly and I can view, duplicate, delete, and create files remotely no problem. But when I edit an existing file and try to save it remotely a little spinning wheel pops up on the tab of the file I'm saving and it continues to spin endlessly.
When I start the server a warning pops up saying: 'path.existsSync is now called fs.existsSync.' I'm not sure if that is relevant or not.
I found another thread somewhere saying that I should go through cloud9/configs/default.js and replace any instance of localhost with 0.0.0.0. I tried that, but it didn't fix my problem.
Does anyone have any suggestions about how to get cloud9 saving files properly?
Thanks in advance for your help.
There were several complains about IDE file saving hangs on cloud9 support. At the bottom of the page there is a solution you can try.
I fully removed cloud9 and node(followed these directions to remove node: Uninstall Node.JS using Linux command line?), and then did a clean install following these directions: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=30265. In addition to those commands I also had to run the following:
sudo npm install formidable
sudo npm install gnu-tools
sudo npm install xmldom
after that I was able to start the cloud9 server without issue, and now I'm able to save files.
thanks for trying to help