This may be a dumb question but does grunt-contrib-watch Watch command only trigger while the terminal is open? Will my grunt commands still trigger if I close the Terminal?
It triggers as long as the grunt process is running. Unless you run it in the background, no, it will not trigger after you close the terminal window.
Related
When I run the firebase emulators:start command on Windows 10, it opens up a console with what looks like a java program outputting log events from the emulator suite. Is there any way to prevent this window from opening?
Thanks!
edit: This window doesn't even close after emulators:exec finishes its command, preventing a proper cleanup.
First of all , this link can help you on how to shutdown correctly the JVMs:
Shut down JVM when Firebase emulator closes
Since you're talking about Java console , then you should use javaw.exe instead of java.exe ! Javaw prevents logs from appearing in console . I'm not an expert of firebase but I believe there's a config file in which there's a call to Java binary which launches the JVM and finally change the java by javaw
firebase-tools is an NPM package that uses the JVM. It includes an emulators:start command which fires up the JVM, and it has the JVM use some ports (defined in settings) for the emulators' input/output.
I use MacOS. I use a VSCode terminal to start/end the emulators, and define the details of how to start using an NPM script. Like this:
npm run build && firebase emulators:start --only functions,auth,firestore,database --import ./db-temp
In other words, run the build script, then start some emulator services.
So when running the emulators, I:
Open a terminal,
Navigate to the folder containing the script
Run the script (npm run serve)
This gives me a convenient place to get feedback from the emulators for things like errors, network activity, etc.
If I close VSCode using VSCode's X button, everything in VSCode is immediately shut down. When the terminal is closed, the JVM doesn't detect this and quit: it keeps running. Then when I open VSCode and try running my script again, it tells me that the port normally used by the emulators is still open, because the JVM didn't shut down properly. So I have to track down the JVM process, Force Quit it, and then everything works fine.
To shut the emulators down properly, I have to go to the terminal process running the emulators, press ALT+C to close the process, and then close VSCode. This extra step is inconvenient, and easily forgotten.
Can I convince the JVM to shut down when its originating process terminates via a configuration option? I looked through the configuration options on my local machine via java and java -x, and didn't see anything promising, but I am sure that there are people who know much more about Java than I do.
The Firebase emulator has an environment variable available for Java configuration.
I would be open to other options if available: telling VSCode to automatically shut down terminals properly before exiting, for example.
Or must this be handled by firebase-tools itself, perhaps via a ShutdownHook?
After a little conversation with Firebase and some troubleshooting, I learned a few things:
This issue only occurs when running firebase emulators:start --only firestore,database: when they run together, the Firestore process never closes. Start either one by itself and everything closes fine. This leads me to suspect that this is a bug.
This is reproducible outside VSCode, leading me to suspect that the issue has nothing to do with VSCode.
I filed https://github.com/firebase/firebase-tools/issues/4657. We'll see how it turns out.
I am using kibana-4.0.0-beta3 version on linux machine. The process gets stopped automatically on closing the putty window. Is there any way to run the process in back-end?
Yes. As with any unix process, the basics would be to use 'nohup' and put the process in the background. You should write a startup script (e.g. /etc/init.d/kibana4) that is similar in form to other startup scripts on your system.
Here is a kibana4 startup script for debian, simply place it in /etc/init.d/kibana , then run:
/etc/init.d/kibana start
set it to start on boot:
update-rc.d kibana defaults
https://github.com/akabdog/scripts/blob/master/kibana4_init
Use a program called screen to run anything in a shell. Then detach from the terminal session but keep the processes running. When you reconnect you can reconnect to the session and interact with them.
Run with nohup
nohub ./bin/kibana
bin/kibana > abc.txt &
This will run kibana in backend and redirect its logs to abc.txt. works like a charm for me :-)
I'm using webstorm for meteor dev.
I've configured a meteor project, and can run my app
however, making a change doesn't trigger the meteor server to restart or rebuild, as it does when running a normal server instance.
Looking at the command being run, they have inserted --once into the command line:
/usr/local/bin/meteor --once run --settings private/local.json
I've added the --settings option in the config dialog.
is there a way to remove that? I guess it will mean a lot of restarts with how webstorm works but so be it. the alternative - manually restarting the whole server all the time is not usable.
http://blog.jetbrains.com/webstorm/2014/09/meteor-support-in-webstorm-9/
When WebStorm runs Meteor it uses the -once which disables Meteor’s
auto reload feature. The reason for this is that the way it currently
works is incompatible with WebStorms autosave option. We are working
with the Meteor team/community to try and think of ways in which we
could provide this feature from within WebStorm. But that it still in
the works.
WebStorm's autosave feature is evil, and hundreds of people have complained about it.
WebStorm should run meteor without the --once parameter, which will enable you to save when you deem it's a good time to do so. To that effect, disable Appearance & Behavior -> System settings -> Save files on frame deactivation and Save files automatically if..., and assign a keyboard shortcut to File -> Save or File -> Save All.
UPDATE
Funny how this has -1 votes, when JetBrains has recognized the problem and fixed the issue in WebStorm.
I couldn't find a way to remove it but I was able to create a Bash script to run my server command instead of doing it in the console. I'm using PhpStorm I believe it should be the same.
The first thing you need to do is create a simple bash script which is essentially is the code you'd run in console. Below is my code:
#!/usr/bin/env bash
meteor --settings settings.json
Once the file is created, go to Run->Edit Configurations.
Under Defaults select Bash and click the plus sign at the top left of the modal.
Name your script. Name:
Reference your script. Script:
Select Run '[Script Name]' from the Run menu.
Hopefully this is helpful and helps a few people.
I am running the BrowserStackTunnel.jar by the grunt plugin grunt-exec
(Have been using node's child_process.exec, but same results)
with the command java -jar BrowserStackTunnel.jar -force APIKEY localhost,8000,false
What the Java file actualy does is connecting via ssh to an Amazon instance of Browserstack and opening a port on 45691, the website of browserstack is polling that port on localhost where the Java application serves a small snippet containing the params passed.
If i run the command from the CLI it works fine and i see the port beeing open on netstat. In the browserstack website i get the success screen.
But if i run the command from grunt-exec it shows only the SYN request.
The output to the command line is the same, both show success
I am not so sure what is causing this. I am running on windows7, node v0.10.12, grunt-cli v0.1.9, grunt v0.4.1 and grunt exec v0.4.2
Any idea what is causing this or how to debug it? I thought about a permission problem, but i am kind of clueless
I had the same problem and I realized, better if I use the BrowserStackLocal binary files for creating a tunel. I solved a quite complex configuration here: Ember.js - CircleCI - BrowserStack
BrowserStackLocal files are here: http://www.browserstack.com/local-testing (Binaries)
Have you tried using the Browserstack Chrome Plugin? It was launched this january and allows you to test local files without running the cli tunnel.
As soon as the child process is created, grunt moves on to the next command. If there is nothing, the grunt process terminates and takes the child with it.
Try adding a grunt-contrib-watch task after the grunt-exec call. It should keep the grunt process alive, and the child process with it.