[nodejs] Forever with ssh

Just use:
-Chad

use "screen"

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





From: nodejs@googlegroups.com On Behalf
Of rhasson
Sent: Tuesday, October 16, 2012 11:22 AM
To: nodejs@googlegroups.com
Subject: Re: [nodejs] Forever with ssh



use "screen"

On Tuesday, October 16, 2012 10:24:40 AM UTC-4, Chad Engler wrote:

Just use:
-Chad

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



-Chad



From: nodejs@googlegroups.com On Behalf
Of Chad Engler
Sent: Tuesday, October 16, 2012 11:53 AM
To: nodejs@googlegroups.com
Subject: RE: [nodejs] Forever with ssh



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





From: nodejs@googlegroups.com On Behalf
Of rhasson
Sent: Tuesday, October 16, 2012 11:22 AM
To: nodejs@googlegroups.com
Subject: Re: [nodejs] Forever with ssh



use "screen"

On Tuesday, October 16, 2012 10:24:40 AM UTC-4, Chad Engler wrote:

Just use:
-Chad

+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

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.

On Tue, Oct 16, 2012 at 9:03 PM, Julian Lannigan
wrote:

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

On Tue, Oct 16, 2012 at 5:33 PM, Julian Lannigan
wrote:

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.

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 =).

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.

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: nodejs@googlegroups.com On Behalf
Of Matt
Sent: Wednesday, October 17, 2012 2:29 PM
To: nodejs@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.



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.

On Wed, Oct 17, 2012 at 12:59 PM, Jimb Esser wrote:

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 =).



On Wednesday, October 17, 2012 6:33:02 AM UTC-7, Matt Sergeant wrote:

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.

On Wed, Oct 17, 2012 at 12:09 AM, Axel Kittenberger
wrote:

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


On Tue, Oct 16, 2012 at 5:33 PM, Julian Lannigan

wrote:
>
http://www.rackaid.com/resources/linux-screen-tutorial-and-how-to/
>
>
>
>
wrote:
>>
>>
>>
Engler wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
On Behalf
>>>
that it continues
>>>
app.js however I
be used like a
>>>
>>>
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
to the Google
nod...@googlegroups.com To
>>
>>
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
to the Google
nod...@googlegroups.com
>
>
>
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines

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 :).

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

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.

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.

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

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.

+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.

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
wrote:

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

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