When I was building on Windows, I was able to hit CTRL-C, which would disconnect Meteor from the localhost and allow me to run meteor reset. I’m now on OSX and CTRL-C only disconnects from the localhost (browser shows it is disconnected) however meteor reset returns:
reset: Meteor is running.
This command does not work while Meteor is running your application. Exit the running Meteor development server.
Someone suggested: kill -9 ps ax | grep node | grep meteor | awk '{print $1}' but that had no result.
I’ve also seen topics online suggesting I check where Meteor installed mongodb, but I’m hoping to find a simpler solution before I start digging that deeply. I have to imagine I am missing something simple, given CTRL-C did everything needed on Windows. Am I wrong or is there a simple solution here? Thank you.
In principle you should have exactly the same behaviour in OSX or linux. However, you also need to be aware of foreground, background and detached processes.
When you type meteor in the shell (console), an instance of the meteor process is started in the foreground. While it is running, you have no interaction with your shell until you either kill the process (for example by using CTRL-C) or stop the process (using CTRL-Z). A killed process is dead and gone - you can use meteor reset if you wish. A stopped process is still there with all its resources open. It can be put back into foreground using the fg command, or into background using the bg command. If it’s in background, you get your shell (console) back even though the meteor process continues to run. If you want, you can start meteor in background from the get-go by typing meteor & into the shell.
You can check for stopped or background processes using the jobs command. You can bring these into foreground (for killing with CTRL-C) using the fg command (or fg %jobnumber if there’s more than one - for example fg %2).
Foreground, background and stopped processes are normally terminated when you log out. However, it’s also possible to detach a process from your shell, so that it continues to run even when you log off. This is likely why you were pointed at kill -9 ps ax | grep node | grep meteor | awk '{print $1}' as a possible solution (although kill -9 is way more severe than the effect of a CTRL-C and I wouldn’t really recommend it unless you know what you are doing). Read the wikipedia article on signals for more information.
I would start by looking at your processes to see if there are any node processes around which you need to deal with (meteor runs as a node process - thanks @mordrax):
ps ax | grep node | grep -v grep
The first column (if there are any) shows the process id of that node process. To simulate the effect of a CTRL-C I would use kill -2 processid (for example, kill -2 12345) and check the list again. If you cannot kill a process with kill -2, you could try kill -9, but this can have consequences like leaving semaphore files in place, making it difficult to recover from (this may have happened to you).
well that’s not going to work, you’re filtering for all node processes, then piping that to filter for all meteor
take the | grep meteor out, meteor runs on a node thread.
Thank you very much @robfallows (and @mordrax), lots for me to digest there. I am on a different machine today but will work through this tonight. In advance though, to confirm: [quote=“robfallows, post:2, topic:16313”]
A killed process is dead and gone - you can use meteor reset if you wish.
[/quote]
Am I reading that correctly that CTRL-C should allow me to use meteor reset? This is the key part that works perfectly in my IDE in Windows but not in OSX.
I guess I can say this is resolved because if I restart my computer I am able to use CTRL-C properly.
This is what I see in the terminal before restarting:
Brendans-MacBook-Pro:Workshop BrendanCahill$ meteor reset
reset: Meteor is running.
This command does not work while Meteor is running your application. Exit the running Meteor development server.
Brendans-MacBook-Pro:Workshop BrendanCahill$ ps ax | grep node | grep -v grep
Brendans-MacBook-Pro:Workshop BrendanCahill$
Brendans-MacBook-Pro:Workshop BrendanCahill$ ps ax | grep node
2742 s000 S+ 0:00.00 grep node
Brendans-MacBook-Pro:Workshop BrendanCahill$ kill -2 2742
bash: kill: (2742) - No such process
Brendans-MacBook-Pro:Workshop BrendanCahill$
I didn’t get any results from the the command you had provided so I tried a subset of it, which gave me the number 2742. Tried to kill it but says no such process.
This is specifically happening after I try a build with an initial collection insertion of about 500 documents (about 30k loc). This collection loaded fine in the past, but I added data to some embedded documents and now the build freezes on Building for web.browser. I need to manually close the terminal and reopen. When I do so, the port is still open and I get these Meteor is still running errors. It’s not a very large data set, and certainly not much bigger than the version that worked before, don’t know why it freezes up.
That’s because you identified the process id of grep (which is what I filtered out with grep -v grep). By the time you entered your kill command, grep had gone away naturally.
If you cannot find any node processes and you can resolve the issue with a reboot it sounds like something else is hanging around which is confusing meteor. I’ve tried several ways of breaking it here, but haven’t replicated your issue yet.
I need to read up more myself to understand grep, thank you for your note there.
This is definitely coming down to this collection I am trying to populate on build (500 documents, 30k loc, 21,500 total populated fields). This is financial data I am using in the place of an eventual third-party API. When I commented out this file, everything built fine. When I included the file, the build froze up on Building for web.browser, and finally succeeded after 12 minutes. I am on METEOR@1.2.1 in OSX.
I created a new project with the same files in Windows (WINDOWS-PREVIEW@0.3.0). The build succeeded without a problem, only took a few seconds. In fact, I can include even more data in the collection, tripling the size of each document, the initial build succeeds in under a couple minutes.
Are there any known bugs for building in OSX that could be related here? Assuming I don’t need to reset my db, it shouldn’t affect my work, but seems like a long delay for an initial build.
):