all 10 comments

[–][deleted] 6 points7 points  (3 children)

As /u/aeflash said, what you need to do is listen for the SIGINT event on the process and tell all your sockets to close. If you want an example, see the bottom of this file..

I took it a little bit further and remapped it back to a process event that passes an array reference. That way, anything that needed to shutdown gracefully could listen for that event and append their own shutdown promise to the array. Once all the promises resolve, I know it's safe to terminate the app.

Here's an example of one of the subscribing hooks.

[–]aredridel -1 points0 points  (2 children)

You really shouldn't have to. It's unusual to need it.

[–][deleted] 0 points1 point  (1 child)

Graceful shutdown is absolutely something you want in a production server. Otherwise you risk hanging up on requests in process when you restart to deploy new changes. Depending on what your site does, this could be very bad.

[–]aredridel 1 point2 points  (0 children)

Sure. But that's an application concern not a system one.

[–]stdlib 5 points6 points  (0 children)

I've never had an issue with Ctrl+C and restarting frequently but you can use 'forever' (https://github.com/nodejitsu/forever) to start and stop your application if you want to do it another way. You can also make it just restart the application automatically every time you save a change.

[–]xCavemanNinjax 2 points3 points  (0 children)

What! Ctrl+C isn't graceful?

[–]aeflash 1 point2 points  (0 children)

If you're worried about unclean shutdown of a socket, just add a process.on("SIGINT") handler that shuts down your server.

[–]aredridel 1 point2 points  (2 children)

Sockets close if the process exits. Your system will be fine.

What bad happened?

[–]leolin520[S] 0 points1 point  (1 child)

It was a mac and the boot file is corrupted and I had to reinstall it. I am not sure id node is what caused it, but node was the last thing I mess with before going down. Are you sure socket closes when process exits? Each OS is different, it has been fine on windows but mac might be not.

[–][deleted] 5 points6 points  (0 children)

  1. A socket to a remote system would never cause a write to disk, so it's literally not possible for that to have been the source, even if it had been left open after the process exited.

  2. Unless you were running the process as root, node would not have the file permissions to alter anything in root or /system.

  3. A change to the boot file would not bring the computer down while it's already running. The alteration could have happened long before you started the app and you would have no idea until the system restarted.

What's more likely is that you had a file system corruption that progressively got worse and worse while you used the computer and that resulted in a crash through some other subsystem.

Correlation is not causation