Forever with ssh

[William Myers]

Is that a way to run forever in an ssh connection so that it continues to run even after the connection has been severed?

Currently, I have only had success with $ nohup node app.js however I would like to use forever and thought that it could be used like a daemon tool to keep a process going.

[Chad Engler]

Just use:

> forever start <script>

And see what is running:

> forever list

And stop a script:

> forever stop <index_or_script_name>

-Chad

--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com To
unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[rhasson]

use "screen"

[Julian Lannigan]

+1 for screen

some links:

http://www.rackaid.com/resources/linux-screen-tutorial-and-how-to/

http://www.gnu.org/software/screen/manual/screen.html

Julian Lannigan

[Anand George]

nohup also seems a good option. Used with supervisor it also tracks code changes.

nohup supervisor app.js &

All logs are sent to nohup.out in the current folder by default.

[Chad Engler]

Forever daemonizes the processes, there is no need for screen. From the README:

 

  actions:

    start               Start SCRIPT as a daemon

    stop                Stop the daemon SCRIPT

    stopall             Stop all running forever scripts

    restart             Restart the daemon SCRIPT

    restartall          Restart all running forever scripts

    list                List all running forever scripts

...

  [Daemon]

    The forever process will run as a daemon which will make the target process start

    in the background. This is extremely useful for remote starting simple node.js scripts

    without using nohup. It is recommended to run start with -o -l, & -e.

    ex. forever start -l forever.log -o out.log -e err.log my-daemon.js

        forever stop my-daemon.js

 

(bold added by me). I use this in production and it works fine.

 

-Chad

[Chad Engler]

Note we also use --pidFile so we can monitor the process with monit as well.

 

-Chad

[Axel Kittenberger]

+2 for screen. I also run my node.js daemon in a "screen".

[Matt]

It does bother me a bit that people are running their node daemons in "screen". Can I at least presume this isn't for production?

I highly recommend using runit - it restarts on failure and is very simple to install and use, and handles logging (including timestamping and log rotation), privilege dropping, and environment variable setting.

[Jimb Esser]

Is there a problem with running in "screen"?  I've very little actual Linux experience, but we've been very happy with running ours in "screen", lets us trivially get both the aspects of a daemon, automatic logging all output to one stream, and be able to connect to it interactively when things need to be debugged.  In general, we still need something like runit to actually launch the screen'd node process, and re-launch it if it fails, but I don't see why running in a screen would be bad (but am by no means an expert =).

[Matt]

I'm no sysadmin, but I've created/worked on some extremely large systems (thousands of machines) and nobody running anything in production environments would ever use screen for keeping things running. It's just not designed for that. It has horrendous potential scenarios for disaster by people pressing the wrong keys. It doesn't deal with log rotation or storage or timestamping. It doesn't deal with restarting failed processes. It's designed for interactive use. It's in no way designed as a secure keep-alive system for daemons.

Compare that to: http://smarden.org/runit/benefits.html

I think if you hired a sysadmin (at least one worth what you pay him) he would replace your "screen" based system in a flash.

On the other hand, I do use screen for everything else, and have it constantly logged in doing "tail -F" on all my logs, so I can instantly see what's going on in real time and pause and scroll back those logs if I need to. I just don't use it for keeping daemons running.

[Chad Engler]

Screen is really for having multiple terminals open with only 1 connection, and for working in a space that doesn’t get destroyed if you lose your connection. It isn’t designed to keep a process running in a production environment. Upstart, monit, forever, and other solutions are.

 

-Chad

 

From: nod...@googlegroups.com [mailto:nod...@googlegroups.com] On Behalf Of Matt
Sent: Wednesday, October 17, 2012 2:29 PM
To: nod...@googlegroups.com
Subject: Re: [nodejs] Forever with ssh

 

I'm no sysadmin, but I've created/worked on some extremely large systems (thousands of machines) and nobody running anything in production environments would ever use screen for keeping things running. It's just not designed for that. It has horrendous potential scenarios for disaster by people pressing the wrong keys. It doesn't deal with log rotation or storage or timestamping. It doesn't deal with restarting failed processes. It's designed for interactive use. It's in no way designed as a secure keep-alive system for daemons.

[ico]

It probably depends on your needs.

Do you need to start your app after system reboot?
Do you need to monitor your app and restart it if it hangs?

And anyway, tmux is better than screen :).

http://groups.google.com/group/nodejs?hl=en?hl=en

--
ico

[William Myers]

Chad,

I would agree with you and that is what I expected forever start <script> to do however when I disconnect ssh then forever is also exiting. With another ssh connection I check the running of the application with ps aux while I am simultaneously connect and after to confirm what I am seeing online with the app. 

Can you or someone else confirm this behavior? Otherwise, I will have to go with 'screen' as a possible solution or see if I can get vm console access to run forever in the 'actual' console.

[Matt]

Why are you so hung up on using forever? It's written in node which means it can't have safe locking, it is far from 100% proven and solid. Just use something proven instead.

[Mark Hahn]

+1 for monit  --  I started using it recently and it was easy and full-featured.

[Axel Kittenberger]

I use it for development and testing-semi-production. You are very
right there are far superior tools. If you take Williams question
literally "I started something manually through ssh, but when I closed
the connection it died". "screen" is the answer to exactly that
problem. Maybe its good to tell, "screen is a solution to the problem
you are seeing, but actually you want to take it beyond that", or
maybe its just that

Kind regards,
Axel

[Tim Caswell]

I run all my sites using upstart.

http://creationix.com/
http://howtonode.org/
http://nodebits.org/
http://luvit.io/

The sites themselves are mostly static content, so I don't need
cluster or anything. The auto-restart directive in upstart keeps them
running between crashes and server reboots perfectly.

On Thu, Oct 18, 2012 at 10:59 PM, Jacob Groundwater
<groun...@gmail.com> wrote:
> +1 for upstart - I think using the platform native tools is good form
>
> It can also be complimented with
> [start-stop-daemon](http://man.he.net/man8/start-stop-daemon) when required.
>
> On Thursday, October 18, 2012 6:39:24 AM UTC-7, Clay Simmons wrote:
>>
>> I like using upstart on Ubuntu to keep my node process running. Not sure
>> if this is considered bad form, but I've been using it in production for
>> about 8 months without any issues.
>>
>> https://gist.github.com/3911822
>>
>> If you're using screen, not to keep your node processes running, but just
>> for doing things in the shell, I would recommend giving tmux a try.

[William Myers]

I appreciate everyone's great insight and I will go with upstart!

[Jacob Groundwater]

I have been using Foreman to run my jobs locally which can also export upstart jobs.

Foreman is a ruby gem however, so over the weekend I decided to port a Node version of foreman. http://nodefly.github.com/node-foreman/

I will be adding to the module over the next few weeks, if anyone would like to help field test it, it would be much appreciated. It can export upstart jobs that are not foreman dependent, so that should lower the risk of using it.

Thanks!

- Jacob Groundwater