restart when files change? about forever

[indexzero]

Thanks to @mmalecki here for implementing this. Will be published in 0.6.8

[indexzero]

Interesting. I'll leave this open.

[eliaskg]

+1 for me. Right now if I want to roll out a new version of my app I run

forever stopall
git pull
forever start server.js

If forever would observe code there would be only one command.
Also forever would be usable in development as an alternative to node-dev.

[Marak]

I'm putting in a +1 from @tmpvar :-)

[derek]

If looking for ideas on how to implement, @davglass's spark2 has a '--watch' command that does this. It's very handy. https://github.com/davglass/spark2/blob/master/bin/spark2#L126

[ded]

glad this conversation got sparked up again :)

[indexzero]

Commits are welcome. I'm looking at you: @tmpvar, @ded and @drgath :-D

Overall it's probably a ~40-50 line change ... I'm heading back from SF to NYC tonight will see what I can do over the weekend. I'm still just one man though...

[guybrush]

you could use githooks

[ded]

i suppose i can have a peak at the source -- but something tells me i'd get lost quickly.

[indexzero]

@ded I'm in #nodejitsu most of the time if you want to chat about this. Most of the nuts and bolts to this change would be in monitor.js. The code is pretty well documented with method level granularity.

[derek]

I played around with it for a little bit tonight. Mostly referenced Dav's code. See lines 650-660: https://github.com/davglass/spark2/blob/master/bin/spark2#L650

It's really easy to monitor one file and fire off a restart event when it is edited. For this though, you'd want to monitor the whole tree and I'd want to investigate the performance/memory impacts and determine the appropriate poll time (ms). A couple files? No prob. But with NPM includes, forever currently checks in at 136 files. It would probably be fine, just haven't investigated yet. Here's the watchFile() function that Node will use. https://github.com/joyent/node/blob/master/lib/fs.js#L592

You'll also want to be sure to only restart once within {x} seconds, not one time for any file change within the tree. A git pull could wreak havoc. :)

Also, something Isaac mentioned in his Supervisor README, you'll want to keep an eye on memory leaks. As you spawn off new children, you'll want to make sure you clean up after yourself. forever might already do this, I haven't dug deep enough to know yet, this is my first time reviewing this module. Lots of editing could drastically increase the # of restarts compared to what forever is used to.

Finally, it appears this could be very useful functionality in a separate module considering how many process spawners make use of this pattern. Reminds me of event delegation in a DOM tree. Sample: require('stat-delegation').monitor(someDir, someCallback);

[indexzero]

@drgath Thanks for looking into this. There is already a good module for watching an entire directory tree: https://github.com/mikeal/watch

In @isaacs node-supervisor project, he watches the entire directory by default. This can become more problematic in npm > 1.0 because of the node_modules folder as you mentioned. Forever now has a global configuration available:

  config           Lists all forever user configuration
  set <key> <val>  Sets the specified forever config <key>
  clear <key>      Clears the specified forever config <key>

We could configure some default options (maybe watch-ignore?) which could ignore certain files by default. You're right that you would want to have some kind of setTimeout when handling file changes so that multiple file changes close in time do not cause multiple restarts.

This is tangentially related to this issue: https://github.com/indexzero/forever/issues/52 which requests adding a minimum interval between process restarts.

Let me know your thoughts and thanks again for your comment.

[diversario]

+1 to this. Just started using Forever and I'm definitely missing automatic restarts (I used node-supervisor).

[clintandrewhall]

+1 I use @Rem's nodemon. I'd love to be able to start it "forever". :-)

[clintandrewhall]

I'd propose a .foreverignore file, rather than edit in config? Or specify a file name of ignored paths/files?

[clintandrewhall]

If anyone's interested, I was able to create a work-around using @Rem's nodemon and a git hook:

#!/bin/sh
GIT_WORK_TREE=[SOME PATH]
export GIT_WORK_TREE
git checkout -f

...and then...

forever start -c nodemon [SOME_PATH]/server.js ...

[indexzero]

@clintandrewhall Interesting hack, but clearly you don't get all of the benefits of forever (such as the new hooks). Anyway, I will take this on soon enough people have been asking about it.

[clintandrewhall]

I'm sorry... in this case, I've been using Forever as:

1. An indexed list of currently-running node instances;
2. A manager of different log outputs;
3. An "auto-restarter" in the case of error, (nodemon halts in those cases)

I'm using a git-sourced nginx configuration as I add apps to a remote server; combined with nodemon, I've been able to restart my apps instantly. I'm afraid I don't see any documentation on the new hooks, (though I haven't delved far into the source code). Can you point me in the right direction, particularly in regards a better approach?

[FGRibreau]

+1 but for now I'll use the workaround:
forever start -c nodemon [SOME_PATH]/server.js ...

[mmalecki]

I'm currently working on this. However, I'm not sure under what conditions should we restart script.

Possibilities:

• when script itself changes
  yeah, but it's 2011 and we have things like require
• when any file in script directory changes
  many node modules have directory structure:

bin/
  executable
lib/
  file.js
  nextfile.js

And what really changes are files in lib, thus it doesn't make sense.

• when anything in parent directory of script changes
  why not parent of parent, then?
• current working directory of forever

$ pwd
/home/maciej
$ forever start /usr/bin/whatever

So, again, it doesn't make sense.

• wrapping each script into context with require replaced
  And no, I don't mean : running it in forever. I mean: let's write a tiny wrapper script, which makes use of VM module, runs script in different context and checks what it requires. We can later watch for changes only on files which application really uses.
  But well, it's hackish. It would require a lot of context mangling (not only require, also process.argv, etc.). I'm not sure if it would be acceptable for production (on the other hand, I think this auto restart mode shouldn't be used in production anyway).

I would really appreciate any feedback on this.

[clintandrewhall]

Why not use a combination of .gitignore and a new .foreverignore file, (the model nodemon uses)?

If the user wants to ignore certain folders, have them configure it? Otherwise, if anything changes in the project, it restarts?

[lbdremy]

+1 it's a great feature that miss to Forever.

[indexzero]

@mmalecki Well put together list of options, thanks for taking this on. It's something I've wanted to implement for a while but just haven't had the time to commit.

I think that a list of file watchers is really the way to go here, working with require statements and a shim can be very fragile. It also won't work for non-nodejs processes (which many users actually run with forever). e.g.

$ forever start -c python somescript.py

The approach suggested by @clintandrewhall is probably most prudent. Just watch everything unless it is in the .gitignore or .foreverignore (also ignore any dotfiles or directories by default, e.g. .git). For the file watching this library: https://github.com/mikeal/watch

[clintandrewhall]

+1 for https://github.com/mikeal/watch I just stumbled upon this library and really like it.

Thanks for looking into this; it'll make my deployments infinitely easier. I use a post-receive git hook on EC2 with a bare repo: git push ec2 and my code goes in and everything restarts. So convenient. :-)

One feature to consider that other monitor solutions don't offer: triggering cleanup or pre-restart tasks. For example, if certain files change (e.g. package.json), run a task/script (e.g. npm install, npm update). I'd be happy to look into adding it after your enhancement work, but it's something to keep in mind?

Thanks again!

[mmalecki]

For the file watching this library: https://github.com/mikeal/watch

Yes, I'm going to use this library.

The approach suggested by @clintandrewhall is probably most prudent. Just watch everything unless it is in the .gitignore or .foreverignore (also ignore any dotfiles or directories by default, e.g. .git).

OK, so this is the way to go. However, I'm not sure about .gitignore. This is usually where output files go, and we may experience cases where file we're running is an output file (e.g. compiled CoffeeScript or just C applications).

Thanks for looking into this; it'll make my deployments infinitely easier. I use a post-receive git hook on EC2 with a bare repo: git push ec2 and my code goes in and everything restarts. So convenient. :-)

I'm using quite similar method for deployments to my server :).

One feature to consider that other monitor solutions don't offer: triggering cleanup or pre-restart tasks. For example, if certain files change (e.g. package.json), run a task/script (e.g. npm install, npm update). I'd be happy to look into adding it after your enhancement work, but it's something to keep in mind?

That's in fact a great idea, we would only need to specify when to run actions, etc. Also, keep in mind that forever is content-agnostic, it can run whatever you like, so defining this kinds of actions and hooks in forever itself might not be a good idea.
We may try emitting an event when file changes, what do you think, @indexzero?

[indexzero]

One feature to consider that other monitor solutions don't offer: triggering cleanup or pre-restart tasks. For example, if
certain files change (e.g. package.json), run a task/script (e.g. npm install, npm update). I'd be happy to look into adding it
after your enhancement work, but it's something to keep in mind?

This is interesting, but I'm curious what the CLI api would look like? It seems like a messy problem.

[ded]

wow. awesome. will upgrade soon

[clintandrewhall]

LOVE IT. Thanks for all your effort...!