как остановить сервер node js
Чтобы остановить сервер Node.js, необходимо нажать «Ctrl + C» в терминале, в котором запущен сервер. Ниже приведен пример:
[process был прерван] Видим, что в терминале появилось сообщение, процесс был прерван. Теперь сервер Node.js остановлен и не будет прослушивать соединения.
Также, есть возможность удаленного управления процессами на Node.js. Одним из таких решений является pm2 process manager.
Как остановить сервер в NodeJs?
Здравствуйте!
Я подключился к серверу через SSH. и работаю в консоль PuTTY
Запустил вебсокет сервер..все норм но как её теперь остановить? когда нажимаю на CTRL+C просто закрывает консоль. а теперь как остановить сервер?(и перезагрузить)
- Вопрос задан более трёх лет назад
- 5111 просмотров
5 комментариев
Простой 5 комментариев
killall node
Дилик Пулатов @dilikpulatov Автор вопроса
Сергей Сергей, прям так написать в консоль?
Егор Живагин @Krasnodar_etc
Тебе нужно процесс, запущенный из-под Node.js перезапустить? Или вообще весь сервер, к которому ты подключился?
в консоли так и надо, в консоли не найдешь нужной кнопочки, можно добавить sudo впереди, зависит от версии системы.
Дилик Пулатов @dilikpulatov Автор вопроса
Егор Живагин, нужно перезапустить один из сервер
Решения вопроса 0
Ответы на вопрос 1
это зависит от того, как вы его запускали. Что такое «вебсокет сервер»?
Если просто node server.js
то проще всего killall node или kill _pid_процесса_
Ответ написан более трёх лет назад
Дилик Пулатов @dilikpulatov Автор вопроса
killall node и kill _pid_процесса_ не работает. пишет что такое команда нету
я подключился к сервер через PuTTY
там установлено Виндовс
просто залил свой проект(ведсокет на ноде) и запускал через команду node index.js и все.
нод сервер работает но теперь не могу её остановить.
PuTTY когда нажимаю CTRL+C просто закрывается консоль
и ещё пробовал команду
pkill —signal SIGINT node-chat
node-chat — здесь process.title = ‘node-chat’; в начале файл index.js то есть ID
Дилик Пулатов,
pkill тоже подойдет
да, killall может быть не установлен. Это в общем тоже самое, только убивает все подходящие под паттерн процессы
pkill «node-chat» должен сработать, если действительно задан process.title
О завершении работы Node.js-процессов
Node.js-процессы завершают работу по разным причинам. При этом в некоторых случаях «смерть» процесса можно предотвратить. Например — в ситуации, когда причиной остановки процесса может стать необработанная ошибка. А вот иногда с остановкой процесса ничего поделать нельзя. Например — если её причина кроется в нехватке памяти. В Node.js существует глобальный объект process , являющийся экземпляром класса EventEmitter . Этот объект, при нормальном завершении процесса, генерирует событие exit . Код приложения может прослушивать это событие и, при его возникновении, выполнять, в синхронном режиме, некие операции по освобождению ресурсов.
Существует несколько способов намеренного завершения работы процесса. Среди них — следующие:
process.exit(1)throw new Error()Promise.reject()EventEmitter#emit('error')$ kill
Многие из этих операций часто выполняются случайно, например — это касается неперехваченных ошибок и необработанных исключений. Но одна из них, с которой мы начнём разбор причин завершения Node.js-процессов, была создана с целью дать разработчику возможность вручную завершать процессы.
Ручной выход из процесса
Подход к завершению работы Node.js-процессов, при котором используется команда вида process.exit(code) , это — самый простой и понятный механизм такого рода, который имеется у разработчика. Эта команда весьма полезна при разработке программ, в коде которых есть место, момент достижения которого означает, что работа программы завершена. Значение code , которое передаётся методу process.exit() , является необязательным, оно может принимать значения от 0 до 255, по умолчанию оно устанавливается в 0. 0 означает успешное завершение процесса, любое ненулевое значение говорит о том, что при работе процесса что-то пошло не так. Подобные значения используются различными внешними по отношению к Node.js-процессам программами. Например, если запуск набора тестов завершился с ненулевым кодом, это означает, что системе не удалось успешно выполнить этот набор тестов.
Когда вызывается команда process.exit() , это не приводит к выводу в консоль какого-либо стандартного сообщения. Если вы написали код, в котором этот метод вызывается при возникновении какой-то ошибки, вам надо предусмотреть вывод сведений об этой ошибке, нужно сообщить пользователю программы о проблеме. Например — попробуйте запустить такой код:
$ node -e "process.exit(42)" $ echo $? Этот Node.js-однострочник ничего в консоль не выведет. Правда, воспользовавшись возможностями командной оболочки, можно узнать статус завершения процесса. Пользователь программы, столкнувшись с тем, что она завершила работу подобным образом, не поймёт того, что произошло.
А вот — более удачный пример использования process.exit() . Этот код представляет собой фрагмент программы, в котором, если некий конфигурационный объект настроен неправильно, осуществляется выход из процесса с предварительным выводом сообщения об ошибке:
function checkConfig(config) < if (!config.host) < console.error("Configuration is missing 'host' parameter!"); process.exit(1); >> Теперь пользователю будут понятны причины остановки приложения. Пользователь запускает приложение, оно выдаёт ошибку в консоль, после чего пользователь принимает меры для исправления ситуации.
Стоит отметить, что метод 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 . Вот пример сообщения о необработанном исключении:
/tmp/foo.js:1 throw new TypeError('invalid foo'); ^ Error: invalid foo at Object. (/tmp/foo.js:2:11) . удалено для краткости . at internal/main/run_main_module.js:17:47 Эти данные позволяют нам сделать вывод о том, что ошибка произошла в строке 2, в 11 столбце кода файла foo.js .
Как уже было сказано, глобальный объект process является экземпляром EventEmitter . Его можно использовать для «ловли» неперехваченных ошибок. А именно, его можно настроить на прослушивание события uncaughtException . Вот пример использования такого подхода, когда ошибка перехватывается, после чего отправляется асинхронное сообщение, а уже потом осуществляется выход из процесса:
const logger = require('./lib/logger.js'); process.on('uncaughtException', (error) => < logger.send("An uncaught exception has occured", error, () =>< console.error(error); process.exit(1); >); >); Отклонения промисов очень похожи на выброс ошибок. Промис может быть отклонён либо в том случае, если в нём вызван метод reject() , либо в том случае, если в асинхронной функции будет выброшена ошибка. В этом смысле следующие два примера, в целом, эквивалентны:
Promise.reject(new Error('oh no')); (async () => < throw new Error('oh no'); >)(); А вот пример того, что при выполнении подобного кода выводится в консоли:
(node:52298) UnhandledPromiseRejectionWarning: Error: oh no at Object. (/tmp/reject.js:1:16) . удалено для краткости . at internal/main/run_main_module.js:17:47 (node:52298) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). Отклонённые промисы, в отличие от неперехваченных исключений, не приводят, в Node.js v14, к остановке процесса. В будущих версиях Node.js отклонённые промисы будут завершать работу процессов. Подобные события, как и в случае с событиями ошибок, можно перехватывать с помощью объекта process :
process.on('unhandledRejection', (reason, promise) => <>); В Node.js распространено использование объектов-источников событий, основанных на классе EventEmitter . Множество таких объектов, кроме того, применяется в библиотеках и приложениях. Эти объекты настолько популярны, что, говоря об ошибках и отклонённых промисах, стоит подробнее обсудить и их.
Когда объект EventEmitter выдаёт событие error , и при этом нет прослушивателя, ожидающего появления этого события, объект выбросит аргумент, который был выдан в виде события. Это приведёт к выдаче ошибки и станет причиной завершения работы процесса. Вот пример того, что в подобной ситуации попадает в консоль:
events.js:306 throw err; // Необработанное событие 'error' ^ Error [ERR_UNHANDLED_ERROR]: Unhandled error. (undefined) at EventEmitter.emit (events.js:304:17) at Object. (/tmp/foo.js:1:40) . удалено для краткости . at internal/main/run_main_module.js:17:47
Не забывайте о прослушивании событий в экземплярах EventEmitter , с которыми вы работаете. Это позволит приложению корректно обрабатывать подобные события, не останавливаясь при их возникновении.
Сигналы
Сигналы — это механизм, работа которого обеспечивается операционной системой. Они представляют собой короткие числовые сообщения, отправляемые одной программой другой программе. В качестве названий этих числовых сообщений часто пользуются строковыми именами соответствующих им констант. Например, имени SIGKILL соответствует числовой сигнал с кодом 9 . Сигналы применяют, преследуя различные цели, но надо отметить, что часто они, так или иначе, используются для остановки программ.
В разных операционных системах могут быть определены различные сигналы. Ниже приведён список сигналов, которые, по большей части, универсальны.
SIGHUPSIGINTSIGQUITSIGKILLОстановить программу node.js из командной строки
Я запускаю его с помощью node server.js , а затем закрываю его с помощью Ctrl + Z на Mac. Когда я пытаюсь запустить его снова с помощью node server.js , я получаю следующее сообщение об ошибке:
node.js:201 throw e; // process.nextTick error, or 'error' event on first tick ^ Error: listen EADDRINUSE at errnoException (net.js:670:11) at Array.0 (net.js:771:26) at EventEmitter._tickCallback (node.js:192:41) Я неправильно закрываю программу? Как я могу предотвратить это? node.js command
Поделиться Источник 09 мая 2012 в 19:05
19 ответов
Чтобы завершить программу, вы должны использовать Ctrl + C . Если вы это сделаете, она отправляет SIGINT , что позволяет программе завершаться красиво, отвязывая от любых портов, на которые она слушает. См. также: https://superuser.com/a/262948/48624
Поделиться 09 мая 2012 в 19:16
Ctrl + Z приостанавливает его, что означает, что он все еще может быть запущен. Ctrl + C фактически уничтожит его. Вы также можете убить его вручную, как показано ниже:
ps aux | grep node Найдите идентификатор процесса (второй слева):
kill -9 PROCESS_ID Это также может работать
killall node Поделиться 09 мая 2012 в 19:21
Или, как альтернатива, вы можете сделать все это в одной строке:
kill -9 $(ps aux | grep '\snode\s' | awk '') Вы можете заменить node внутри ‘\snode\s’ на любое другое имя процесса.
Поделиться 22 сентября 2014 в 15:17
Возобновите и убейте процесс:
- Дайте команду fg для возобновления процесса на переднем плане.
- введите Ctrl + C , чтобы правильно его убить.
Alternatively, вы можете убить его вручную, как показано ниже:
(NOTE: следующие команды могут требовать root, поэтому sudo. ваш друг)
pkill -9 node или, если у вас нет pkill, это может сработать:
killall node или, возможно, так:
kill $(ps -e | grep node | awk '') Иногда процесс перечисляет свой собственный grep, в этом случае вам понадобится:
kill $(ps -e | grep dmn | awk '') h/t @ruffin из комментариев к самому вопросу. У меня была та же проблема, и его комментарий помог мне решить ее самостоятельно.
Поделиться 26 мая 2017 в 21:48
Если вы интерактивно запускаете Node.js (REPL):
Ctrl + C вернет вас к > prompt, затем введите:
process.exit() или просто используйте Ctrl + D .
Поделиться 15 февраля 2014 в 07:54
Вы можете ввести .exit , чтобы выйти из node js REPL
Поделиться 22 июля 2013 в 10:12
На Linux попробуйте: pkill node
Taskkill /IM node.exe /F from subprocess import call call(['taskkill', '/IM', 'node.exe', '/F']) Поделиться 18 июля 2018 в 18:26
$ sudo killall node в другом терминале работает на mac, в то время как killall node не работает:
$ killall node No matching processes belonging to you were found Поделиться 18 июня 2013 в 12:53
Вы можете работать с следующей командой, чтобы быть конкретной в локальном kill server (здесь: 8000)
$:lsof -i tcp:8000 Она даст вам следующие группы TCP:
КОМАНДА ПИД ИСПОЛЬЗОВАТЕЛЯ FD ТИПЕ РАЗМЕР РАЗМЕРОС/ИМЯ НОДА
node 21521 ubuntu 12u IPv6 345668 0t0 TCP *:8000 (LISTEN)
$:kill -9 21521 Она убьет processId, соответствующий TCP*:8000
Поделиться 17 августа 2019 в 13:42
Вы можете использовать fuser, чтобы получить то, что вы хотите сделать.
Для получения идентификаторов процессов задач, работающих на порту, вы можете сделать следующее:
fuser >/tcp Допустим, порт 8888, команда становится:
fuser 8888/tcp А чтобы убить процесс, работающий на порту, просто добавьте переключатель -k.
fuser >/tcp -k Пример (порт 8888):
fuser 8888/tcp -k Вот и все! Он закроет процесс, прослушивающий порт. Я обычно делаю это перед запуском моего серверного приложения.
Поделиться 08 декабря 2019 в 16:57
- Откройте терминал
- Запустите следующий код и нажмите Enter
sudo kill $(sudo lsof -t -i:4200)
Поделиться 29 августа 2019 в 06:11
Хотя это поздний ответ, я нашел это в документации NodeJS:
Событие ‘exit’ испускается при выходе из REPL либо путем получения команды .exit в качестве входного значения, пользователь дважды нажимает -C , чтобы сигнализировать о сигнале, либо путем нажатия -D , чтобы сигнализировать о завершении входного потока. Обратный вызов слушателя вызывается без аргументов.
Таким образом, чтобы суммировать, вы можете выйти:
- Ввод .exit в REPL nodejs.
- Нажатие -C дважды.
- Нажатие -D .
- process.exit(0) означает естественный выход из REPL. Если вы хотите вернуть любой другой статус, вы можете вернуть ненулевое число.
- process.kill(process.pid) — это способ убить с помощью API nodejs из вашего кода или из REPL.
Поделиться 22 сентября 2016 в 16:41
Я добавляю этот ответ, потому что для многих проектов с производственными развертываниями у нас есть скрипты, которые останавливают эти процессы, поэтому нам не нужно.
Чистый способ управления процессами вашего сервера Node — использовать пакет forever (из NPM ).
Пример:
Установка Forever
npm install forever -g
Запуск сервера Node
forever start -al ./logs/forever.log -ao ./logs/out.log -ae ./logs/err.log server.js
Результат:
info: Forever processing file: server.js
Отключение сервера Node
forever stop server.js
Результат
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 ~/.forever/forever.log 0:0:0:0.247
Это очистит отключение вашего серверного приложения.
Поделиться 08 июля 2017 в 18:40
Если вы хотите остановить свой сервер с помощью npm stop или чего-то подобного, вы можете написать код, который убивает ваш серверный процесс, как:
require('child_process').exec(`kill -9 $`) Поделиться 31 января 2016 в 03:06
Я столкнулся с проблемой, когда у меня запущено несколько серверов узлов, и я хочу просто убить один из них и переразвернуть его из скрипта.
Примечание: Этот пример находится в оболочке bash на Mac.
Для этого я убежден, что мой вызов node максимально конкретен. Например, вместо вызова node server.js из директории приложений, я вызываю node app_name_1/app/server.js
Затем я могу убить его, используя:
kill -9 $(ps aux | grep ‘node\ app_name_1/app/server.js’ | awk »)
Это только убивает процесс node, запускаемый app_name_1/app/server.js.
Если вы запустили node app_name_2/app/server.js , этот процесс node продолжит работу.
Если вы решите, что хотите убить их всех, вы можете использовать kill node , как упоминали другие.
Поделиться 06 июля 2017 в 02:51
Поздний ответ, но на Windows, открытие диспетчера задач с помощью CTRL+ALT+DEL, а затем убийство процессов Node.js решит эту ошибку.
Поделиться 20 октября 2018 в 04:32
Для Windows сначала найдите PID с номером вашего порта
netstat -ano | findStr "portNumber" 
После этого убедитесь, что вы находитесь в корне вашего диска «c» И команда будет taskkill /F /PID your pid
Поделиться 12 июня 2019 в 14:35
Если вы используете VS Code и терминал, сначала выберите узел из правой части раскрывающегося списка, а затем выполните Ctrl + C. Тогда это будет работать
Нажмите y, когда вам будет предложено.
Поделиться 11 апреля 2020 в 12:44
Мой случай использования: на MacOS, запуск/перезапуск нескольких серверов узлов на различных портах из скрипта
запуск: «cd $PATH1 && node server1.js & cd $PATH2 && node server2.js &. «
остановка1: «kill -9 $(lsof -nP -i4TCP:$PORT1 | grep LISTEN | awk »)»
остановка: «stop1 & stop2 &. & stopN ; запуск
для получения дополнительной информации о поиске процесса по порту: Кто слушает данный TCP-порт на Mac OS X?