How to terminate a HTTP server in Node.js?
One of the most popular support questions I answer is a variation of “how to terminate a HTTP server” or “why does HTTP server not stop after calling server.close() ". The reason for that is described in the documentation of server.close() :
server.stop() stops the server from accepting new connections and keeps existing connections. This function is asynchronous, the server is finally closed when all connections are ended and the server emits a 'close' event.
i.e. when you call server.close() , server stops accepting new connections, but it keeps the existing connections open indefinitely. This can result in your server hanging indefinitely due to persistent HTTP connections or because of the ongoing requests that do not produce a response. Therefore, in order to close the server, you must track creation of all connections and terminate them yourself.
The basic principle of forcefully closing a HTTP server looks like this:
However, abruptly terminating a HTTP server is not desirable. You want to give time for existing requests to complete (without accepting new requests) and you want to inform the client that it should not attempt to use the same connection again (in case of persist HTTP connections). All of this can be done using an abstraction such as http-terminator .
http-terminator implements the logic for tracking all connections and their termination upon a timeout. http-terminator also ensures graceful communication of the server intention to shutdown to any clients that are currently receiving response from this server.
Terminating a server using http-terminator is as simple as instantiating the service referencing the HTTP server instance and calling terminate method:
By default, http-terminator gives 1 second for the server to complete the request. This can be configured using httpResponseTimeout configuration.
how to stop node.js server
from a putty terminal to get it running. Now i want to stop the server how should i do it? I tried pressing the pause break button on the keyboard. But it is not stopping it.
7 Answers 7
Try using ctrl+c , usually does the trick.
Try from another terminal
Works in OS X and Linux. It may also prevent respawning node processes. For instance if a node some_server.js is running it may that any normal kill command (even kill -9 <PID_of_that_process> will simply result in a respawn node some_server.js process with a different PID. In that situation the only way to kill it is: killall node . I solved this issue on Redhat Linux RHEL7 but it should work the same for most Linux OS.
If you are going to use the ‘top’ command to kill a process, you should try sending the ‘2’ signal first, not ‘9’. Sending ‘9’ is kind of like pulling the plug on your computer instead of issuing a shutdown command. It can sometimes have some undesirable consequences. Sending ‘2’ has the same effect as ctrl+c .
For reference, here are the different signals you can send to stop a process and what they mean: (from kill man page)
![]()
Enter ‘top’ at command line and find the process ID of the process you want to kill. Press ‘K’, it will prompt you to enter the process id that you want to kill, enter it, and press enter. It will then ask what signal you want to transmit to the process, enter ‘9’ and press enter. The process will be killed.
On windows os in command prompt, Press CTRL + C wait till it stops if it does not then Press the CTRL + C 2 times this will definitely work.
![]()
ctrl + shift + c does the trick in ubuntu terminal
I had the same problem while running npm from Babun and then i tried to use Windows CMD instead (because i had similar problem running git commands from Babun) and that showed different results.
When i run npm from CMD, i had to click Enter so that the script gets executed and then i was asked to click w to show more details.
I clicked w and that showed :
Watch Usage
› Press f to run only failed tests.
› Press o to only run tests related to changed files.
› Press p to filter by a filename regex pattern.
› Press t to filter by a test name regex pattern.
› Press q to quit watch mode.
› Press Enter to trigger a test run.
I clicked w and npm was stopped and returned control to CMD.
-
The Overflow Blog
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
Site design / logo © 2023 Stack Exchange Inc; user contributions licensed under CC BY-SA . rev 2023.3.11.43304
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.
О завершении работы Node.js-процессов
Node.js-процессы завершают работу по разным причинам. При этом в некоторых случаях «смерть» процесса можно предотвратить. Например — в ситуации, когда причиной остановки процесса может стать необработанная ошибка. А вот иногда с остановкой процесса ничего поделать нельзя. Например — если её причина кроется в нехватке памяти. В Node.js существует глобальный объект process , являющийся экземпляром класса EventEmitter . Этот объект, при нормальном завершении процесса, генерирует событие exit . Код приложения может прослушивать это событие и, при его возникновении, выполнять, в синхронном режиме, некие операции по освобождению ресурсов.
Существует несколько способов намеренного завершения работы процесса. Среди них — следующие:
| Операция | Пример |
| Ручной выход из процесса | |
| Неперехваченная ошибка | |
| Необработанное отклонение промиса | |
| Проигнорированное событие error | |
| Необработанный сигнал |
Ручной выход из процесса
Подход к завершению работы Node.js-процессов, при котором используется команда вида process.exit(code) , это — самый простой и понятный механизм такого рода, который имеется у разработчика. Эта команда весьма полезна при разработке программ, в коде которых есть место, момент достижения которого означает, что работа программы завершена. Значение code , которое передаётся методу process.exit() , является необязательным, оно может принимать значения от 0 до 255, по умолчанию оно устанавливается в 0. 0 означает успешное завершение процесса, любое ненулевое значение говорит о том, что при работе процесса что-то пошло не так. Подобные значения используются различными внешними по отношению к Node.js-процессам программами. Например, если запуск набора тестов завершился с ненулевым кодом, это означает, что системе не удалось успешно выполнить этот набор тестов.
Когда вызывается команда process.exit() , это не приводит к выводу в консоль какого-либо стандартного сообщения. Если вы написали код, в котором этот метод вызывается при возникновении какой-то ошибки, вам надо предусмотреть вывод сведений об этой ошибке, нужно сообщить пользователю программы о проблеме. Например — попробуйте запустить такой код:
Этот Node.js-однострочник ничего в консоль не выведет. Правда, воспользовавшись возможностями командной оболочки, можно узнать статус завершения процесса. Пользователь программы, столкнувшись с тем, что она завершила работу подобным образом, не поймёт того, что произошло.
А вот — более удачный пример использования process.exit() . Этот код представляет собой фрагмент программы, в котором, если некий конфигурационный объект настроен неправильно, осуществляется выход из процесса с предварительным выводом сообщения об ошибке:
Теперь пользователю будут понятны причины остановки приложения. Пользователь запускает приложение, оно выдаёт ошибку в консоль, после чего пользователь принимает меры для исправления ситуации.
Стоит отметить, что метод process.exit() — это весьма мощный механизм. Хотя у него есть своё место в коде приложений, его категорически не рекомендуется использовать в библиотеках, рассчитанных на многократное использование. Если ошибка произошла в библиотеке, библиотека должна её выбросить. Это позволит приложению, использующему библиотеку, самостоятельно принять решение о том, как обрабатывать эту ошибку.
Исключения, отклонения промисов, выдача событий error
Метод process.exit() — это полезный инструмент, применимый для борьбы с ошибками, возникающими при запуске программ и при наличии проблем с их первоначальными настройками. Но он не очень хорошо подходит в тех случаях, когда речь идёт об ошибках времени выполнения. Тут нужны другие инструменты. Например, когда приложение занимается работой с HTTP-запросами, ошибка, возникшая в ходе обработки запроса, вероятно, не должна приводить к остановке процесса. Программа всего лишь должна вернуть ответ с сообщением об ошибке. Тут пригодятся и сведения о том, где именно произошла ошибка. Именно в подобных ситуациях очень кстати оказываются объекты Error .
Экземпляры класса Error содержат метаданные, которые полезны в деле определения причины ошибки. Например — данные трассировки стека и строки с сообщениями об ошибке. Распространённой является практика построения на основе класса Error классов ошибок, рассчитанных на конкретное приложение. При этом одно лишь создание экземпляра класса Error не приводит к каким-то заметным последствиям. Экземпляр ошибки нужно не только создать, но и выбросить.
Ошибки выбрасывают, используя ключевое слово throw . Ошибки, при наличии каких-то проблем в коде, могут выбрасываться и автоматически. Когда это происходит — производится «раскручивание» стека вызовов. То есть — происходит выход из всех функций, цепочка вызовов которых привела к достижению места выброса ошибки. Делается это до тех пор, пока не будет достигнута функция, в которой соответствующий вызов помещён в выражение try/catch . После этого ошибка перехватывается и вызывается код, который имеется в ветви выражения catch . Если же при вызове кода, в котором была выброшена ошибка, выражение try/catch не использовалось, такая ошибка считается неперехваченной.
Хотя предполагается, что ключевое слово throw нужно использовать лишь для выбрасывания ошибок (например — так: throw new Error(‘foo’) ), оно, с технической точки зрения, позволяет «выбрасывать» всё что угодно. Если что-то выброшено с помощью throw — это «что-то» считается исключением. Настоятельно рекомендуется выбрасывать с помощью throw именно экземпляры класса Error , так как код, который перехватывает объекты, выброшенные throw , весьма вероятно, рассчитывает на то, что это будут объекты, представляющие ошибки и имеющие соответствующие свойства.
Среди свойств объектов-ошибок можно отметить свойство .code , представляющее код ошибки. Оно было популяризировано благодаря его использованию во внутренних Node.js-библиотеках. Это свойство содержит задокументированное строковое значение, которое не должно меняться между релизами системы. В качестве примера кода ошибки можно привести ERR_INVALID_URI . Несмотря на то, что описание ошибки, предназначенное для программистов и хранящееся в свойстве .message , может меняться, то, что хранится в свойстве .code , меняться не должно.
К сожалению, один из широко распространённых подходов, используемых для различения ошибок, заключается в исследовании свойства .message соответствующих объектов. А ведь значение этого свойства в разных версиях системы вполне может меняться. Это — рискованный и чреватый ошибками подход к обработке ошибок. Правда, надо сказать, что в экосистеме Node.js не существует идеального механизма различения ошибок, который подходит для работы со всеми существующими библиотеками.
Когда выбрасывается ошибка, которая оказывается неперехваченной, в консоль выводятся данные трассировки стека, осуществляется выход из процесса со статусом завершения процесса 1 . Вот пример сообщения о необработанном исключении:
Эти данные позволяют нам сделать вывод о том, что ошибка произошла в строке 2, в 11 столбце кода файла foo.js .
Как уже было сказано, глобальный объект process является экземпляром EventEmitter . Его можно использовать для «ловли» неперехваченных ошибок. А именно, его можно настроить на прослушивание события uncaughtException . Вот пример использования такого подхода, когда ошибка перехватывается, после чего отправляется асинхронное сообщение, а уже потом осуществляется выход из процесса:
Отклонения промисов очень похожи на выброс ошибок. Промис может быть отклонён либо в том случае, если в нём вызван метод reject() , либо в том случае, если в асинхронной функции будет выброшена ошибка. В этом смысле следующие два примера, в целом, эквивалентны:
А вот пример того, что при выполнении подобного кода выводится в консоли:
Отклонённые промисы, в отличие от неперехваченных исключений, не приводят, в Node.js v14, к остановке процесса. В будущих версиях Node.js отклонённые промисы будут завершать работу процессов. Подобные события, как и в случае с событиями ошибок, можно перехватывать с помощью объекта process :
В Node.js распространено использование объектов-источников событий, основанных на классе EventEmitter . Множество таких объектов, кроме того, применяется в библиотеках и приложениях. Эти объекты настолько популярны, что, говоря об ошибках и отклонённых промисах, стоит подробнее обсудить и их.
Когда объект EventEmitter выдаёт событие error , и при этом нет прослушивателя, ожидающего появления этого события, объект выбросит аргумент, который был выдан в виде события. Это приведёт к выдаче ошибки и станет причиной завершения работы процесса. Вот пример того, что в подобной ситуации попадает в консоль:
Не забывайте о прослушивании событий в экземплярах EventEmitter , с которыми вы работаете. Это позволит приложению корректно обрабатывать подобные события, не останавливаясь при их возникновении.
Сигналы
Сигналы — это механизм, работа которого обеспечивается операционной системой. Они представляют собой короткие числовые сообщения, отправляемые одной программой другой программе. В качестве названий этих числовых сообщений часто пользуются строковыми именами соответствующих им констант. Например, имени SIGKILL соответствует числовой сигнал с кодом 9 . Сигналы применяют, преследуя различные цели, но надо отметить, что часто они, так или иначе, используются для остановки программ.
В разных операционных системах могут быть определены различные сигналы. Ниже приведён список сигналов, которые, по большей части, универсальны.
| Имя | Код | Подлежит ли сигнал обработке | Стандартная реакция Node.js | Цель сигнала |
| 1 | Да | Завершение работы | Закрытие терминала | |
| 2 | Да | Завершение работы | Сигнал прерывания (Ctrl+C) с терминала | |
| 3 | Да | Завершение работы | Сигнал Quit с терминала (Ctrl+D) | |
| 9 | Нет | Завершение работы | Безусловное завершение процесса | |
| 10 | Да | Запуск отладчика | Пользовательский сигнал №1 | |
| 12 | Да | Завершение работы | Пользовательский сигнал №2 | |
| 15 | Да | Завершение работы | Запрос на завершение работы процесса | |
| 19 | Нет | Завершение работы | Остановка выполнения процесса |
Если в программе может быть реализован механизм обработки соответствующего сигнала — в столбце таблицы «Подлежит ли сигнал обработке» стоит «Да». Два сигнала из таблицы с «Нет» в этой колонке обработке не подлежат. В столбце «Стандартная реакция Node.js» описана стандартная реакция Node.js-программы на получение соответствующего сигнала. В столбце «Цель сигнала» приведено описание стандартного общепринятого подхода к использованию сигналов.
Для обработки этих сигналов в Node.js-приложении можно воспользоваться уже знакомым нам механизмом объекта process по прослушиванию событий:
Запустите эту программу в терминале, а потом нажмите Ctrl + C . Процесс не остановится. Вместо этого он сообщит о том, что получил сигнал SIGINT . Переключитесь на другое окно терминала и выполните следующую команду, использовав в ней идентификатор процесса ( Process ID ), выведенный вышеприведённым кодом:
Эти эксперименты призваны продемонстрировать то, как одна программа может отправлять сигналы другой программе. В ответ на эту команду Node.js-программа, работающая в другом терминале и получившая сигнал SIGHUP , выдаст соответствующее сообщение.
Возможно, вы уже догадались о том, что Node.js-программы могут отправлять сообщения другим программам. Выполните следующую команду, которая демонстрирует отправку сообщения от короткоживущего процесса работающему процессу:
В ответ на эту команду наш процесс покажет то же SIGHUP-сообщение, что показывал ранее. А если же работу этого процесса нужно завершить, ему надо отправить необрабатываемый сигнал SIGKILL :
Stop node.js program from command line
I start it with node server.js and then close it with Ctrl + Z on Mac. When I try to run it again with node server.js I get this error message:
Am I closing the program the wrong way? How can I prevent this from happening?
19 Answers 19
To end the program, you should be using Ctrl + C . If you do that, it sends SIGINT , which allows the program to end gracefully, unbinding from any ports it is listening on.
![]()
Ctrl + Z suspends it, which means it can still be running.
Ctrl + C will actually kill it.
you can also kill it manually like this:
Find the process ID (second from the left):
This may also work
Or alternatively you can do all of these in one line:
You can replace node inside ‘\snode\s’ with any other process name.
![]()
Resume and kill the process:
You are likely now at a terminal prompt.
Give the command fg to resume the process in the foreground.
type Ctrl + C to properly kill it.
Alternatively, you can kill it manually like this:
(NOTE: the following commands may require root, so sudo . is your friend)
or, if you don’t have pkill, this may work:
or perhaps this:
sometimes the process will list its own grep, in which case you’ll need:
h/t @ruffin from the comments on the question itself. I had the same issue and his comment helped me solve it myself.
![]()
If you are running Node.js interactively (the REPL):
Ctrl + C will take back you to > prompt then type:
or just use Ctrl + D .
![]()
![]()
you can type .exit to quit node js REPL
$ sudo killall node in another terminal works on mac, while killall node not working:
on linux try: pkill node
you can work following command to be specific in localserver kill(here: 8000)
It will give you following groups of TCPs:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
node 21521 ubuntu 12u IPv6 345668 0t0 TCP *:8000 (LISTEN)
It will kill processId corresponding to TCP*:8000
You can use fuser to get what you want to be done.
In order to obtain the process ids of the tasks running on a port you can do:
Let’s say the port is 8888, the command becomes:
And to kill a process that is running on a port, simply add -k switch.
Example (port is 8888):
That’s it! It will close the process listening on the port. I usually do this before running my server application.
![]()
-
Open terminal
Run the below code and hit enter
![]()
Though this is a late answer, I found this from NodeJS docs:
The ‘exit’ event is emitted when the REPL is exited either by receiving the .exit command as input, the user pressing <ctrl>-C twice to signal SIGINT, or by pressing <ctrl>-D to signal ‘end’ on the input stream. The listener callback is invoked without any arguments.
So to summarize you can exit by:
- Typing .exit in nodejs REPL.
- Pressing <ctrl>-C twice.
- pressing <ctrl>-D .
- process.exit(0) meaning a natural exit from REPL. If you want to return any other status you can return a non zero number.
- process.kill(process.pid) is the way to kill using nodejs api from within your code or from REPL.
If you want to stop your server with npm stop or something like this. You can write the code that kill your server process as:
I’m adding this answer because for many projects with production deployments, we have scripts that stop these processes so we don’t have to.
A clean way to manage your Node Server processes is using the forever package (from NPM ).
Example:
Install Forever
npm install forever -g
Run Node Server
forever start -al ./logs/forever.log -ao ./logs/out.log -ae ./logs/err.log server.js
Result:
info: Forever processing file: server.js
Shutdown Node Server
forever stop server.js
Result
info: Forever stopped process: uid command script forever pid id logfile uptime [0] sBSj «/usr/bin/nodejs/node»
/path/to/your/project/server.js 23084 13176
This will cleanly shutdown your Server application.
![]()
I ran into an issue where I have multiple node servers running, and I want to just kill one of them and redeploy it from a script.
Note: This example is in a bash shell on Mac.
To do so I make sure to make my node call as specific as possible. For example rather than calling node server.js from the apps directory, I call node app_name_1/app/server.js
Then I can kill it using:
kill -9 $(ps aux | grep ‘node\ app_name_1/app/server.js’ | awk ‘
This will only kill the node process running app_name_1/app/server.js.
If you ran node app_name_2/app/server.js this node process will continue to run.
If you decide you want to kill them all you can use killall node as others have mentioned.