Процессы (process)


Объект process является глобальным объектом, который предоставляет информацию и контролирует текущий процесс Node.js. Как глобальный объект, он всегда доступен приложениям Node.js без необходимости вызова require().

События процессов (Process Events)

Объект process является экземпляром EventEmitter.

Event: 'beforeExit'

Добавлено в v0.11.12

Событие ‘beforeExit’ генерируется тогда, когда Node.js исчерпывает цикл событий и не имеет другой назначенной работы. Обычно процесс Node.js завершается, когда нет назначенной работы, но слушатель, зарегестрированный в событии ‘beforeExit’ может совершать асинхронные вызовы, и тем самым побудить процесс Node.js продолжаться.

Функция обратного вызова слушателя имеет значение process.exitCode, которое передается в качестве единственного аргумента.

Событие ‘beforeExit’ не генерируется при условиях, которые служат причиной явного прекращения процесса, таких, например, как process.exit() или неотслеженные исключения.

‘beforeExit’ не должно использоваться как альтернатива событию ‘exit’, за исключением случаев, когда нужно назначить дополнительную работу.

Event: 'disconnect'

Добавлено в v0.7.7

Если процесс Node.js был порожден с использованием IPC канала (см. документацию по Child Process и Cluster), генерируется событие ‘disconnect’, когда канал IPC закрыт.

Event: 'exit'

Добавлено в v0.1.7

Событие ‘exit’ генерируется, когда процесс Node.js закрывается, вследствие следующего:

  • метод process.exit() был вызван явно
  • цикл событий Node.js больше не содержит дополнительной работы

Нет способов предотвратить выход из цикла событий в таком случае, и, когда все слушатели ‘exit’ завершаются, процесс Node.js будет прекращен.

Функция обратного вызова слушателя вызывается с кодом выхода, заданным либо свойством process.exitCode, либо аргументом exitCode, передаваемым в метод process.exit() в качестве единственного аргумента.

Например:


process.on('exit', (code) => {
  console.log(`About to exit with code: ${code}`);
});

Функции слушателей должны выполнять исключительно синхронные операции. Процесс Node.js завершается непосредственно после вызова слушателей события ‘exit’, которые заставляют процесс не обращать внимания на любую дополнительную работу в очереди. В этом примере, например, никогда не произойдет timeout:


process.on('exit', (code) => {
  setTimeout(() => {
    console.log('This will not run');
  }, 0);
});

Event: 'message'

Добавлено в v0.5.10

Если процесс Node.js порождается с использованием IPC канала, генерируется событие ‘message’, тогда, когда родительским процессом отправляется сообщение по childprocess.send(), получает дочерний процесс.

Функция обратного вызова вызывается со следующими аргументами:

  • message <Объект> распарсенный объект JSON или примитивное значение
  • sendHandle <объект обработчика> объект net.Socket или net.Server, или неопределенное значение

Event: 'rejectionHandled'

Добавлено в v1.4.1

Событие ‘rejectionHandled’ генерируется, когда отклоняется Promise и позже добавляется обработчик ошибок (с использованием, например, promise.catch()), позднее одного прохода цикла.

Функция обратного вызова слушателя вызывается со ссылкой на отклоненный Promise как единственный аргумент.

Объект Promise будет предварительно сгенерирован в событии ‘unhandledRejection’, но в процессе обработки получает обработчик отказа.

Нет никаких упоминаний высших уровней цепи Promise, на которых могут обрабатываться отказы. Будучи наследованно асинхронным, отказ Promise может быть обработан в какой-либо момент в будущем, - возможно, намного позже, чем нужно времени циклу событий для генерации события ‘unhandledRejection’.

Можно утверждать, что, в отличие от синхронного кода, где есть постоянно растущий список необработанных исключений, у Promises будет растущий и сокращающийся список необработанных отказов.

В синхронном коде событие ‘uncaughtException’ генерируется, когда растет список необработанных исключений.

В асинхронном коде событие ‘unhandledRejection’ генерируется, когда список необработанных отказов растет, а когда он уменьшается, генерируется событие ‘rejectionHandled’.

Пример:


const unhandledRejections = new Map();
process.on('unhandledRejection', (reason, p) => {
  unhandledRejections.set(p, reason);
});
process.on('rejectionHandled', (p) => {
  unhandledRejections.delete(p);
});

В этом примере карта Map unhandledRejection будет расти и уменьшаться с течением времени, отображая те самые отказы, которые сначала были необработанными, а потом стали обработанными. Возможно записывать такие ошибки в журнал ошибок, либо периодически (что лучше всего для долгоработающего приложения), либо при закрытии процесса (что более удобно для скриптов).

Event: 'uncaughtException'

Добавлено в v0.1.18

Событие ‘uncaughtException’ генерируется в том случае, когда неотслеженное исключение JavaScript все время всплывает в цикле событий. По умолчанию, Node.js обрабатывает такие исключения посредством вывода на экран стэка трассировки в stderr и последующим закрытием. Добавление обработчика в событие ‘uncaughtException’ перезаписывает поведение по умолчанию.

Функция слушателя вызывается с объектом Error, передаваемым в качестве единственного аргумента.

Например:


process.on('uncaughtException', (err) => {
  fs.writeSync(1, `Caught exception: ${err}`);
});

setTimeout(() => {
  console.log('This will still run.');
}, 500);

// Intentionally cause an exception, but don't catch it.
nonexistentFunc();
console.log('This will not run.');

Предупреждение: корректное использование ‘uncaughtException’

Заметьте, что ‘uncaughtException’ является довольно сырым механизмом обработки исключений, который стоит применять только в самом крайнем случае. Событие не должно использоваться как эквивалент On Error Resume Next. Необработанные исключения по существу означают, что приложение находится в неопределенном положении. Попытки возобновить код приложения без четкого восстановления из исключение могут повлечь за собой дополнительные непредвиденные и непредсказуемые проблемы.

Исключения, которые выдаются из обработчика событий, не отслеживаются. Вместо этого процесс закрывается с ненулевым кодом выхода и на экран выводится стэк трассировки. Это делается во избежание бесконечной рекурсии.

Попытки возобновить запуск в обычном режиме после неотслеженного исключения подобны выдергиванию вилки питания из розетки при обновлении компьютера – девять из десяти приведут к нулевому результату, а десятая может привести к повреждению системы.

Корректное использование ‘uncaughtException’ – выполнение синхронный очистки выделенный ресурсов (файловых дескрипторов, обработчиков и т.п.) перед закрытием процесса. Небезопасно возобновлять нормальные операции после вызова ‘uncaughtException’

Для перезапуска приложения более надежным способом, вне зависимости от того, генерируется uncaughtException или нет, следует мониторить приложение из отдельного процесса для обнаружения ошибок и перезапуска или восстановления по мере надобности.

Event: 'unhandledRejection'

Добавлено в v1.4.1

Событие ‘unhandledRejection’ генерируется, когда Promise получает отказ и на очередном витке цикла событий нет обработчика ошибок для Promise. При программировании с Promises, исключения инкапсулируются как ‘rejected promises’. Отказы могут быть получены и обработаны с использованием promise.catch() и могут передаваться через цепь Promise. Событие ‘unhandledRejection’ полезно использовать для обнаружения и хранения списка отказанных promises, чьи отказы еще не были обработаны.

Функция слушателя вызывается с такими аргументами:

  • reason <Ошибка> | <любое значение> Объект, с которым promise получил отказ (обычно объект Error)
  • p отказанный Promise

Пример:


process.on('unhandledRejection', (reason, p) => {
  console.log('Unhandled Rejection at: Promise', p, 'reason:', reason);
  // тут прописываются заданные логи приложения, выпадение ошибки или другая логика
});

somePromise.then((res) => {
  return reportToUser(JSON.pasre(res)); // обратите внимание на опечатку (`pasre`)
}); // нет ни `.catch`, ни`.then`

Нижеприведенный пример заставляет генерироваться событие ‘unhandledRejection’


function SomeResource() {
  // изначально устанавливает статус загрузки отказанному promise
  this.loaded = Promise.reject(new Error('Resource not yet loaded!'));
}

var resource = new SomeResource();
// нет .catch или .then в resource.loaded по крайней мере для одного прохождения цикла

В данном конкретном случае возможно отследить отказ как ошибку разработчика, и это, как правило, будет иметь место и для других событий ‘unhandledRejection’. Для того, чтобы адресовать такие ошибки, нужно применить неоперационный обработчик .catch(() => { }) в resource.loaded, что поможет предотвратить генерацию события ‘unhandledRejection’. Так же в качестве альтернативы можно использовать событие ‘rejectionHandled’.

Event: 'warning'

Добавлено в v6.0.0

Событие ‘warning’ генерируется тогда, когда Node.js генерирует предупреждение для процесса.

Предупреждение для процесса подобно ошибке в том, что оно описывает исключительные условия, которые пользователь должен принять во внимание. Однако, предупреждения не являются частью нормального потока обработки ошибок Node.js и Javascript. Node.js может генерировать предупреждения тогда, когда обнаруживает плохой код, что может привести к неоптимальной производительности приложения, багам или уязвимости безопасности.

Функция слушателя вызывается с единственным аргументом warning, чье значение является объектом Error. Есть три ключевых свойства, описывающих предупреждения:

  • name <Строка> Имя предупреждения (по умолчанию сейчас это Warning)
  • message <Строка> Предоставленное системой описание предупреждения
  • stack <Строка> Стэк трассировки того места в коде, к которому относится предупреждение

process.on('warning', (warning) => {
   console.warn(warning.name);    // Выводит на экран имя предупреждения
   console.warn(warning.message); // Выводит на экран сообщение предупреждения
   console.warn(warning.stack);   // Выводит на экран стэк трассировки
	});

По умолчанию Node.js записывает предупреждения процесса в stderr. Опция командной строки --no-warnings может использоваться для того, чтобы убрать вывод консоли, но событие ‘warning’ все равно будет генерироваться объектом process.

Этот пример иллюстрирует, как предупреждения выводятся в stderr, когда у события слишком много слушателей:


$ node
> event.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> (node:38638) Warning: Possible EventEmitter memory leak detected. 2 foo
... listeners added. Use emitter.setMaxListeners() to increase limit

Следующий пример, напротив, показывает выключение вывода предупреждений по умолчанию и добавляет кастомный обработчик в событие ‘warning’:


$ node --no-warnings
> var p = process.on('warning', (warning) => console.warn('Do not do that!'));
> event.defaultMaxListeners = 1;
> process.on('foo', () => {});
> process.on('foo', () => {});
> Do not do that!

Опцию командной строки --trace-warnings можно использовать для включения в вывод консоли предупреждений по умолчанию полный стэк трассировки предупреждений.

Запуск Node.js с использованием флага командной строки --throw-deprecation может привести к тому, что кастомные предупреждения отказа будут выпадать как исключения.

Использование флага командной строки --throw-deprecation может повлечь за собой вывод кастомного отказа в stderr наряду со стэком трассировки.

Использование флага командной строки --no-deprecation может подавить все отчеты о кастомных отказах.

Флаги командной строки *-deprecation влияют только на предупреждения, которые имеют имя DeprecationWarning.

Генерация кастомных (пользовательских) предупреждений.

См. метод process.emitWarning().

Сигнальные события (Signal Events)

Сигнальные события генерируются, когда процесс Node.js получает сигнал. См. signal(7) для получения полного списка имен стандартных сигналов POSIX, таких, как SIGINT, SIGHUP и т.п.

Имя каждого события должно быть набрано верхним регистром, общим для сигналов (‘SIGINT’ для сигналов SIGINT).

Пример:


// Начинайте чтение из stdin, чтобы процесс не закрылся
process.stdin.resume();

process.on('SIGINT', () => {
  console.log('Received SIGINT.  Press Control-D to exit.');
});

Примечание: легкий способ отправить сигнал SIGINT в большинстве терминальных программ – использовать <Ctrl>-C.

Важно запомнить следующее:

  • SIGUSR1 резервируется Node.js для запуска дебаггера. Можно установить слушатель, но это все равно не оставит запуск дебаггера.
  • SIGTERM и SIGINT имеют дефолтные обработчики на платформах, отличных от Wndows, которые сбрасывают режим терминала перед завершением с кодом 128 + signal number. Если один из этих сигналов имеет установленный слушатель, его поведение по умолчанию будет удалено (Node.js больше не будет завершаться).
  • SIGPIPE по умолчанию игнорируется. У него может быть установленный слушатель.
  • SIGHUP генерируется на Windows, когда закрывается окно консоли, на других платформах также при подобных условиях (см. signal(7)). Он может иметь установленный слушатель, однако, Node.js будет закрыт Windows спустя 10 секунд. На отличных от Windows платформах поведение SIGHUP по умолчанию заключается в принудительном завершении Node.js, но с установкой слушателя это поведение удаляется.
  • SIGTERM не поддерживается на Windows, может иметь слушатель.
  • SIGINT из терминала поддерживается на всех платформах и может быть сгенерирован посредством CTRL+C (можно перенастроить). Не генерируется, когда включен «сырой» режим терминала.
  • SIGBREAK работает на Windows, когда нажато <Ctrl> + <Break>, на не-Windows платформах его можно слушать, но нельзя отправить или сгенерировать.
  • SIGWINCH получается, когда изменятся консоль. На Windows это происходит, когда при записи в консоль двигается курсор, или когда читаемый tty используется в сыром режиме.
  • SIGKILL не может иметь установленный слушатель, может принудительно завершить Node.js на всех платформах.
  • SIGSTOP не может иметь установленный слушатель.
  • SIGBUS, SIGFPE, SIGSEGV и SIGILL, когда они не вызываются искусственно посредством kill(2), по сути покидают процесс в том состоянии, из которого небезопасно пытаться вызываться слушателей JS. Попытки сделать это могут привести к зависанию процесса в бесконечном цикле, так как слушатели применяются с помощью асинхронного вызова process.on(), и, вследствие этого не могут исправить основную проблему.

Примечание: Windows не поддерживает отправляемые сигналы, но Node.js предлагает эмуляцию этого через process.kill() и ChildProcess.kill(). Отправка сигнала 0 может использоваться для проверки существования процесса. Отправка SIGINT, SIGTERM и SIGKILL может привести к безоговорочному прекращению целевого процесса.

process.abort()

Добавлено в v0.7.0

Метод process.abort() заставляет процесс Node.js немедленно закрываться с созданием core-файла.

process.arch

Добавлено в v0.5.0
  • <Строка>

Свойство process.arch возвращает строку, определяющую архитектуру процессора, на котором на текущий момент запущен Node.js. Например, ‘arm’, ‘ia32’, ‘x64’.


console.log(`This processor architecture is ${process.arch}`);

process.argv

Добавлено в v0.1.27
  • <Массив>

Свойство process.argv возвращает массив, содержащий аргументы командной строки, передаваемые при запуске процесса Node.js. Первый элемент будет process.execPath. См. process.argv0, если нужен доступ к изначальному значению argv[0]. Второй элемент – это путь к выполняемому файлу JavaScript. Остальные элементы будут дополнительными аргументами командной строки.

Например, предполагается такой скрипт для process-args.js:


// выводим на экран process.argv
process.argv.forEach((val, index) => {
  console.log(`${index}: ${val}`);
});

Запускаем процесс Node.js:


$ node process-2.js one two=three four

Будет генерироваться следующее:


0: /usr/local/bin/node
1: /Users/mjr/work/node/process-2.js
2: one
3: two=three
4: four

process.argv0

Добавлено в v6.4.0
  • <Строка>

Свойство process.argv0 выделяет копию изначального значения argv[0], открытую только для чтения, которая передается при запуске Node.js.


$ bash -c 'exec -a customArgv0 ./node'
> process.argv[0]
'/Volumes/code/external/node/out/Release/node'
> process.argv0
'customArgv0'

process.channel

Добавлено в v7.1.0

Если процесс Node.js был создан с IPC каналом (см. документацию по дочерним процессам), свойство process.channel будет являться ссылкой на IPC канал. Если нет IPC канала, то свойство имеет значение undefined.

process.chdir(directory)

Добавлено в v0.1.17
  • directory <Строка>

Метод process.chdir() изменяет текущую рабочую директорию процесса Node.js и выдает исключение, если не удалось это выполнить (например, если заданная директория не существует).


console.log(`Starting directory: ${process.cwd()}`);
try {
  process.chdir('/tmp');
  console.log(`New directory: ${process.cwd()}`);
}
catch (err) {
  console.log(`chdir: ${err}`);
}

process.config

Добавлено в v0.7.7
  • <Объект>

Свойство process.config возвращает объект, содержащий JavaScript представление опций конфигурации, которые используются для компилирования текущего выполняемого процесса Node.js. Является тем же самым, что и файл config.gypi, который создается при запуске скрипта ./configure/

Пример возможных выходов:


{
  target_defaults:
   { cflags: [],
     default_configuration: 'Release',
     defines: [],
     include_dirs: [],
     libraries: [] },
  variables:
   {
     host_arch: 'x64',
     node_install_npm: 'true',
     node_prefix: '',
     node_shared_cares: 'false',
     node_shared_http_parser: 'false',
     node_shared_libuv: 'false',
     node_shared_zlib: 'false',
     node_use_dtrace: 'false',
     node_use_openssl: 'true',
     node_shared_openssl: 'false',
     strict_aliasing: 'true',
     target_arch: 'x64',
     v8_use_snapshot: 'true'
   }
}

Примечание: свойство process.config не является открытым только для чтения, и существуют модули в экосистеме, которые могут увеличивать, изменять или полностью замещать значение process.config.

process.connected

Добавлено в v0.7.2
  • <Boolean>

Если процесс Node.js был создан с IPC каналом (см. документацию по дочерним процессам и кластерам), свойство process.connected будет возвращать true все время, пока IPC канал подключен и false после вызова process.disconnect().

Если process.connected() имеет значение false, больше не представляется возможным отправлять сообщения по IPC каналу, используя process.send().

process.cpuUsage([previousValue])

Добавлено в v6.1.0
  • previousValue <объект> Предыдущее возвращенное значение из process.cpuUsage()
  • Возвращает объект
    • user <целое число>
    • system <целое число>

Метод process.cpuUsage() возвращает пользовательское и системное время CPU использования текущего процесса в объект со свойствами user и system, чьи значения выдаются в микросекундах. Эти значения измеряют время, проведенное в пользовательском и системном коде соответственно, и могут в конечном итоге быть больше, чем настоящее время, если работу для этого процесса выполняют несколько ядер CPU.

Результат предыдущего вызова process.cpuUsage() может передаваться в качестве аргумента в функцию для чтения.


const startUsage = process.cpuUsage();
// { user: 38579, system: 6986 }

// работа CPU 500 милисекунд
const now = Date.now();
while (Date.now() - now < 500);

console.log(process.cpuUsage(startUsage));
// { user: 514883, system: 11226 }

process.cwd()

Добавлено в v0.1.8
  • Возвращает строку

Метод process.cwd() возвращает текущую рабочую директорию процесса Node.js


console.log(`Current directory: ${process.cwd()}`);

process.disconnect()

Добавлено в v0.7.2

Если процесс Node.js был создан с IPC каналом, метод process.disconnect() будет закрывать IPC канал для родительского процесса, позволяя дочернему процессу завершиться, если нет никаких других подключений, которые могли бы этому помешать.

Эффект вызова process.disconnect() является аналогом вызова ChildProcess.disconnect() в родительском процессе.

Если процесс Node.js был создан без IPC канала, то значение process.disconnect() будет undefined.

process.emitWarning(warning[, name][, ctor])

Добавлено в v6.0.0
  • warning <Строка>| <Ошибка> генерируемое предупреждение
  • name <Строка> если warning – строка, name – имя предупреждения. По умолчанию: Warning.
  • ctor <функция> если warning – строка, ctor – опциональная функция, используемая для ограничения генерируемого стэка трассировки. По умолчанию: process.emitWarning

Метод process.emitWarning можно использовать для генерации кастомных или заданных приложением предупреждений для процесса. Можно добавить слушателя и обработчик в событие process.on(‘warning’).


// Генерирует предупреждение, используя строку...
process.emitWarning('Something happened!');
// генерирует: (node: 56338) Warning: Something happened!

// Генерирует предупреждение, использую строку и имя..
process.emitWarning('Something Happened!', 'CustomWarning');
// генерирует: (node:56338) CustomWarning: Something Happened!

В каждом из примеров объект Error генерируется внутренне через process.emitWarning() и передается в событие process.on(‘warning’).


process.on('warning', (warning) => {
  console.warn(warning.name);
  console.warn(warning.message);
  console.warn(warning.stack);
});

Если warning передается как объект Error, то оно будет передаваться в неизмененный обработчик события process.on(‘warning’) (опциональные аргументы name и ctor игнорируются):


// генерирует предупреждение, используя объект Error...
const myWarning = new Error('Warning! Something happened!');
myWarning.name = 'CustomWarning';

process.emitWarning(myWarning);
// генерирует: (node:56338) CustomWarning: Warning! Something Happened!

Если warning не является строкой или объектом Error, выпадает TypeError.

Следует заметить, что пока процессные предупреждения используют объекты Error, механизм предупреждения процесса не является заменой нормальному механизму обработки ошибок.

Нижепреведенная дополнительная обработка применяется, если имя предупреждения DeprecationWarning:

  • если используется флаг командной строки --throw-deprecation, предупреждение об отклонении скорее выпадает как исключение, чем генерируется как событие.
  • если используется флаг командной строки --no-deprecation, предупреждение об отклонении подавляется.
  • если используется флаг командной строки --trace-deprecation, предупреждение об отклонении записывается в stderr наряду с полным стэком трассировки.

Избегание дублирующихся предупреждений

Лучше всего, если предупреждения будут генерироваться единожды для одного процесса. Для этого рекомендуется поместить emitWarning() за простым Boolean-флагом, как в примере ниже:


function emitMyWarning() {
  if (!emitMyWarning.warned) {
    emitMyWarning.warned = true;
    process.emitWarning('Only warn once!');
  }
}
emitMyWarning();
// Генерирует: (node: 56339) Warning: Only warn once!
emitMyWarning();
// ничего не генерирует

process.env

Добавлено в v0.1.27
  • <Объект>

Свойство process.env возвращает объект, который содержит пользовательское окружение. См. environ(7).

Пример этого объекта выглядит таким образом:


{
  TERM: 'xterm-256color',
  SHELL: '/usr/local/bin/bash',
  USER: 'maciej',
  PATH: '~/.bin/:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin',
  PWD: '/Users/maciej',
  EDITOR: 'vim',
  SHLVL: '1',
  HOME: '/Users/maciej',
  LOGNAME: 'maciej',
  _: '/usr/local/bin/node'
}

Возможно изменить этот объект, но такие модификации не будут иметь влияние вне процесса Node.js. Другими словами, следующий пример не будет работать:


$ node -e 'process.env.foo = "bar"' && echo $foo

А этот будет:


process.env.foo = 'bar';
console.log(process.env.foo);

Задание свойства process.env неявно конвертирует значение в строку.

Пример:


process.env.test = null;
console.log(process.env.test);
// => 'null'
process.env.test = undefined;
console.log(process.env.test);
// => 'undefined'

Используйте delete для удаления свойства из process.env.

Пример:


process.env.TEST = 1;
delete process.env.TEST;
console.log(process.env.TEST);
// => undefined

На Windows переменные окружения нечувствительны к регистру.

Пример:


process.env.TEST = 1;
console.log(process.env.test);
// => 1

process.execArgv

Добавлено в v0.7.7
  • <Объект>

Свойство process.execArgv возвращает набор опций командной строки Node.js, которые передаются при запуске Node.js. Эти опции не выводятся в массив, возвращаемый свойством process.argv и не включаются в выполняемый процесс Node.js, имя скрипта или любые другие опции, касающиеся имени скрипта. Опции являются полезными, когда нужно породить дочерний процесс с такими же окружением выполнения, как у родительского процесса.

Пример:


$ node --harmony script.js --version

Результат в process.execArgv:
['--harmony']

И process.argv:
['/usr/local/bin/node', 'script.js', '--version']

process.execPath

Добавлено в v0.1.100
  • <Строка>

Свойство process.execPath возвращает абсолютный путь к исполняемому файлу, который запустил процесс Node.js.

Пример:


'/usr/local/bin/node'

process.exit([code])

Добавлено в v0.1.13
  • code <целое число> код выхода. По умолчанию: 0.

Метод process.exit() дает Node.js указание прекратить процесс как можно быстрее с заданным кодом выхода. Если код опускается, используется либо код 0, либо значение process.exitCode, если оно задано.

Для выхода с кодом ошибки:


process.exit(1);

Оболочка, которая выполняет Node.js, должна видеть 1 в качестве кода выхода.

Важно запомнить, что вызов process.exit() заставит процесс завершиться как можно быстрее, даже если все еще выполняются асинхронные операции, включая операции ввода-вывода, в process.stdout и process.stderr.

В большинстве ситуаций нет особой надобности явно вызывать process.exit. Процесс Node.js завершится сам, если в цикл событий не передается никакой дополнительной работы. Свойство process.exitCode может быть установлено для того, чтобы сообщать процессу, какой код выхода использовать, когда процесс завершается.

Следующий пример иллюстрирует последствия злоупотребления методом process.exit(), что может привести к тому, что данные, которые выводятся в stdout, могут быть потеряны:


// пример того, чего делать не стоит:
if (someConditionNotMet()) {
  printUsageToStdout();
  process.exit(1);
}

Причина, почему это так проблематично, состоит в том, что записи в process.stdout иногда являются неблокируемыми и могут осуществляться в течение нескольких периодов цикла событий. Вызов process.exit(), однако, принуждает процесс завершиться перед выполнением этих дополнительных записей в stdout.

Вместо непосредственного вызова process.exit(), код должен установить process.exitCode и позволить процессу завершиться естественным путем, избегая назначения дополнительной работы в цикл событий.


// Как точно задавать код выхода,
// позволяя процессу нормально завершиться.
if (someConditionNotMet()) {
  printUsageToStdout();
  process.exitCode = 1;
}

Если необходимо прекратить процесс Node.js из-за неправильных условий, выдать неперехваченную ошибку и позволить вследствие этого процессу прекратиться – безопаснее, чем вызывать process.exit().

process.exitCode

Добавлено в v0.11.8
  • <целое число>

Число, которые будет кодом выхода процесса, пока процесс завершается нормальным путем или завершается посредством process.exit() без задания кода.

Задание кода в process.exit(code) перезапишет все предыдущие настройки process.exitCode.

process.getegid()

Добавлено в v2.0.0

Метод process.getegid() возвращает числовую идентичность эффективных групп процесса Node.js (см. getegid(2)).


if (process.getegid) {
  console.log(`Current gid: ${process.getegid()}`);
}

Примечание: эта функция доступна только на платформах POSIX (на Windows и Android нет).

process.geteuid()

Добавлено в v2.0.0
  • Возвращает объект

Метод process.geteuid() возвращает числовую идентичность эффективных пользователей процесса (см. geteuid(2)).


if (process.geteuid) {
  console.log(`Current uid: ${process.geteuid()}`);
}

Примечание: эта функция доступна только на платформах POSIX.

process.getgid()

Добавлено в v0.1.31
  • Возвращает объект

Метод process.getgid() возвращает числовую идентичность групп процесса (см. getgid(2)).


if (process.getgid) {
  console.log(`Current gid: ${process.getgid()}`);
}

Примечание: эта функция доступна только на платформах POSIX.

process.getgroups()

Добавлено в v0.9.4
  • Возвращает массив

Метод process.getgroups() возвращает массив дополнительных групповых ID. POSIX может оставить из незаданными, если есть ID эффективных групп, но Node.js всегда задает их.

Примечание: эта функция доступна только на платформах POSIX.

process.getuid()

Добавлено в v0.1.28
  • Возвращает целое число

Метод process.getuid() возвращает числовую идентичность пользователей процесса (см. getuid(2)).


if (process.getuid) {
  console.log(`Current uid: ${process.getuid()}`);
}

Примечание: эта функция доступна только на платформах POSIX.

process.hrtime([time])

Добавлено в v0.7.6

Метод process.hrtime() возвращает текущее реальное время кортежа массива в высоком разрешении (в секундах и наносекундах). time – опциональный параметр, который должен быть результатом предыдущего вызова process.hrtime() (и, следовательно, реальным временем в секундах и наносекундах кортежа массива, содержащего предыдущее время) для получения изменений со временем. Это время является родственным произвольному времени в прошлом и никак не соотносится со временем дня, а следовательно, не может быть субъектом часового хода. Основное использование – для измерения произоводительности между интервалами.

Передача результата предыдущего вызова в process.hrtime() полезна для подсчета времени, которое прошло между вызовами:


var time = process.hrtime();
// [ 1800216, 25 ]

setTimeout(() => {
  var diff = process.hrtime(time);
  // [ 1, 552 ]

  console.log(`Benchmark took ${diff[0] * 1e9 + diff[1]} nanoseconds`);
  // эталонный тест занял 1000000527 наносекунд
}, 1000);

Построение массива любым методом, отличным от process.hrtime() и передача результата в process.hrtime() вызовет непредусмотренное поведение.

process.initgroups(user, extra_group)

Добавлено в v0.9.4
  • user <Строка> | <число> Имя пользователя или числовой идентификатор
  • extra_group <Строка> | <число> Имя группы или числовой идентификатор

Метод process.initgroups() читает файл /etc/group и инициализирует список доступных групп, используя все группы, в которых состоит пользователь. Это привилегированная операция, которая требует от процесса Node.js либо root-доступ, либо возможность CAP_SETGID.

Заметьте, что при отмене привилегии следует быть осторожным. Пример:


console.log(process.getgroups());         // [ 0 ]
process.initgroups('bnoordhuis', 1000);   // переключение между пользователями
console.log(process.getgroups());         // [ 27, 30, 46, 1000, 0 ]
process.setgid(1000);                     // отмена root gid
console.log(process.getgroups());         // [ 27, 30, 46, 1000 ]

Примечание: эта функция доступна только на платформах POSIX.

process.kill(pid[, signal])

Добавлено в v0.0.6
  • pid <число> ID процесса
  • signal <Строка> | <число> Сигнал для отправки, строка либо число. По умолчанию: ‘SIGTERM’.

Метод process.kill() отправляет сигнал в процесс, указанный pid.

Имена сигналов – строки, такие, как ‘SIGINT’ или ‘SIGHUP’. См. события сигналов и kill(2).

Этот метод выдает ошибку, если целевой pid не существует. В особом случае может быть использован сигнал 0 для проверки существования процесса. Windows выдает ошибку, если pid используется для уничтожения группы процессов.

Примечание: Несмотря на то, что эта функция называется process.kill(), на самом деле она используется только для отправки сигналов, как системный вызов kill. Отправленный сигнал не обязательно уничтожает целевой процесс.

Пример:


process.on('SIGHUP', () => {
  console.log('Got SIGHUP signal.');
});

setTimeout(() => {
  console.log('Exiting.');
  process.exit(0);
}, 100);

process.kill(process.pid, 'SIGHUP');

Примечание: когда процесс Node.js получает SIGUSR1, Node.js запускает отладчик. См. события сигналов.

process.mainModule

Добавлено в v0.1.17

Свойство process.mainModule предоставляет альтернативный способ получения require.main. Разница состоит в том, что главный модуль изменяет время запуска, require.main же ссылается на оригинальный главный модуль, который запрашивался до проведения изменений. Обычно можно с полной уверенностью полагать, что эти два свойства ссылаются на один и тот же модуль.

Так же, как и require.main, process.mainModule имеет значение undefined, если нет входящего скрипта.

process.memoryUsage()

Добавлено в v0.1.16
  • Возвращает объект
    • rss <целое число>
    • heapTotal <целое число>
    • heapUsed <целое число>
    • external <целое число>

Метод process.memoryUsage() возвращает объект, описывающий использование памяти процессом Node.js, измеряемое в байтах.

Например, этот код

console.log(process.memoryUsage());

будет генерировать следующее:


{
  rss: 4935680,
  heapTotal: 1826816,
  heapUsed: 650472,
  external: 49879
}

heapTotal и heapUsed ссылаются на использование памяти V8, external ссылается на использование памяти объектами С++, привязанными к объектам JavaScript, которые управляются V8.

process.nextTick(callback[, ...args])

Добавлено в v0.1.26
  • callback <функция>
  • args <любое значение> Дополнительные аргументы для передачи при вызове callback

Метод process.nextTick() добавляет функцию обратного вызова в «очередь следующего периода». После того, как текущий оборот цикла событий подходит к завершению, все функции обратного вызова будут вызваны в очереди следующего периода.

Это не простой заменитель setTimeout(fn, 0). Этот метод более эффективный. Он запускается перед любыми дополнительными событиями I/O (включая таймеры), которые срабатывают в последующем периоде цикла событий.


console.log('start');
process.nextTick(() => {
  console.log('nextTick callback');
});
console.log('scheduled');
// Вывод:
// start
// scheduled
// nextTick callback

Это важно при разработке API, для того, чтобы дать пользователям возможность задавать обработчики событий после создания объекта но перед любыми событиями I/O.


function MyThing(options) {
  this.setupOptions(options);

  process.nextTick(() => {
    this.startDoingStuff();
  });
}

var thing = new MyThing();
thing.getReadyForStuff();

// thing.startDoingStuff() должна быть вызвана сейчас, а не раньше

Для API очень важно быть либо на 100% синхронными, либо на 100% асинхронными. Пример:


// Предупреждение: не использовать этот код! Опасно!
function maybeSync(arg, cb) {
  if (arg) {
    cb();
    return;
  }

  fs.stat('file', cb);
}

Такое API опасно, потому что в этом примере:


maybeSync(true, () => {
  foo();
});
bar();

Непонятно, первым вызывается foo() или bar().

Нижеприведенный способ намного лучше:


function definitelyAsync(arg, cb) {
  if (arg) {
    process.nextTick(cb);
    return;
  }

  fs.stat('file', cb);
}

Примечание: очередь следующего периода иссякает на каждом повороте цикла событий перед обработкой дополнительных вводов-выводов. В результате рекурсивно заданные функции обратного вызова следующего периода заблокируют все вводы-выводы, как цикл while(true).

process.pid

Добавлено в v0.1.15
  • <целое число>

Свойство process.pid возвращает PID процесса.


console.log(`This process is pid ${process.pid}`);

process.platform

Добавлено в v0.1.16
  • <Строка>

Свойство process.platform возвращает строку, определяющую платформу операционной системы, на которой запущен процесс Node.js. Например, ‘darwin’, ‘freebsd’, ‘linux’, ‘sunos’, ‘win32’.


console.log(`This platform is ${process.platform}`);

process.release

Добавлено в v3.0.0

Свойство process.release возвращает объект, содержащий метаданные, родственные текущему релизу, включая URL исходных архиваций и архиваций заголовков.

process.release содержит следующие свойства:

  • name <Строка> Значение, которое всегда будет ‘node’ для Node.js. Для релизов io.js значение меняется на ‘io.js’.
  • sourceUrl <Строка> Абсолютный URL, указывающий на файл .tar.gz, содержащий исходный код текущего релиза.
  • headerUrl <Строка> Абсолютный URL, указывающий на файл .tar.gz, содержащий только исходные заголовочные файлы для текущего релиза. Этот файл является значительно меньшим, чем полный файл источника и может использоваться для компилирования нативных аддонов Node.js.
  • libUrl <Строка> Абсолютный URL, указывающий на файл node.lib, подходящий под архитектуру и версию текущего релиза. Этот файл используется для компилирования нативных аддонов Node.js. Это свойство представлено только на билдах Node.js на Windows и может быть пропущено на остальных платформах.
  • lts <Строка> строковый ярлык, определяющий ярлык LTS для этого релиза. Если релиз Node.js не является LTS, значение будет undefined.

Пример:


{
  name: 'node',
  lts: 'Argon',
  sourceUrl: 'https://nodejs.org/download/release/v4.4.5/node-v4.4.5.tar.gz',
  headersUrl: 'https://nodejs.org/download/release/v4.4.5/node-v4.4.5-headers.tar.gz',
  libUrl: 'https://nodejs.org/download/release/v4.4.5/win-x64/node.lib'
}

В кастомных сборках из нерелизных версий дерева источника предоставляется только свойство name. На дополнительные свойства не следует полагаться до проверки их существования.

process.send(message[, sendHandle[, options]][, callback])

Добавлено в v0.5.9
  • message <Объект>
  • sendHandle <объект обработчика>
  • options <Объект>
  • callback <Функция>
  • Возвращает Boolean.

Если Node.js был порожден с IPC каналом, можно использовать метод process.send() для отправки сообщений родительскому процессу. Сообщения будут получаться событием ‘message’ в объекте ChildProcess родительского процесса.

Если IPC канала нет, process.send() будет иметь значение undefined.

Примечание: эта функция неявно использует JSON.stringify() для сериализации message.

process.setegid(id)

Добавлено в v2.0.0
  • Id <Строка> | <число> Имя группы или ID

Метод process.setegid() устанавливает идентичность эффективных групп процесса (см. setegid(2)). Id может передаваться как числовое ID или как строка, содержащая имя группы. Если задано имя группы, этот метод блокируется, пока находится соответствующее числовое ID.


if (process.getegid && process.setegid) {
  console.log(`Current gid: ${process.getegid()}`);
  try {
    process.setegid(501);
    console.log(`New gid: ${process.getegid()}`);
  }
  catch (err) {
    console.log(`Failed to set gid: ${err}`);
  }
}

Примечание: эта функция доступна только на платформах POSIX.

process.seteuid(id)

Добавлено в v2.0.0
  • Id <Строка> | <число> Имя пользователя или ID

Метод process.seteuid() устанавливает идентичность эффективных пользователей процесса (см. seteuid(2)).

Id может передаваться как числовое ID или как строка, содержащая имя пользователя. Если задано имя пользователя, этот метод блокируется, пока находится соответствующее числовое ID.


if (process.geteuid && process.seteuid) {
  console.log(`Current uid: ${process.geteuid()}`);
  try {
    process.seteuid(501);
    console.log(`New uid: ${process.geteuid()}`);
  }
  catch (err) {
    console.log(`Failed to set uid: ${err}`);
  }
}

Примечание: эта функция доступна только на платформах POSIX.

process.setgid(id)

Добавлено в v0.1.31
  • Id <Строка> | <число> Имя группы или ID

Метод process.setgid() устанавливает идентичность групп процесса (см. setgid(2)). Id может передаваться как числовое ID или как строка, содержащая имя группы. Если задано имя группы, этот метод блокируется, пока находится соответствующее числовое ID.


if (process.getgid && process.setgid) {
  console.log(`Current gid: ${process.getgid()}`);
  try {
    process.setgid(501);
    console.log(`New gid: ${process.getgid()}`);
  }
  catch (err) {
    console.log(`Failed to set gid: ${err}`);
  }
}

Примечание: эта функция доступна только на платформах POSIX.

process.setgroups(groups)

Добавлено в v0.9.4
  • groups <массив>

Метод process.setgroups() устанавливает дополнительные групповые ID для процесса Node.js. Это привилегированная операция, которая требует от процесса Node.js root прав или возможности CAP_SETGID.

Массив groups может содержать как числовые групповые ID, так и имена групп.

Примечание: эта функция доступна только на платформах POSIX.

process.setuid(id)

Добавлено в v0.1.28

Метод process.setuid(id) устанавливает идентичность пользователя процесса (см. setuid(2)).

Id может передаваться как числовое ID или как строка, содержащая имя пользователя. Если задано имя пользователя, этот метод блокируется, пока находится соответствующее числовое ID.


if (process.getuid && process.setuid) {
  console.log(`Current uid: ${process.getuid()}`);
  try {
    process.setuid(501);
    console.log(`New uid: ${process.getuid()}`);
  }
  catch (err) {
    console.log(`Failed to set uid: ${err}`);
  }
}

Примечание: эта функция доступна только на платформах POSIX.

process.stderr

  • <Стрим>

Свойство process.stderr возвращает открытый для записи стрим, эквивалентный или ассоциируемый с stderr (fd 2).

Примечание: process.stderr и process.stdout отличаются от остальных стримов Node.js:

  1. Они не могут быть закрыты (выпадает end())
  2. Они никогда не генерируют событие ‘finish’
  3. Записи могут блокироваться, когда вывод перенаправляется на файл
    • Заметьте, что диски работают быстро и операционные системы обычно обращаются к кэшированию обратной записи, так что это очень редкое явление
  4. Записи на UNIX будут блокироваться по умолчанию, если вывод направляется на TTY (терминал)
  5. Функционал на Windows разный. Записи блокируются, если вывод не направляется на терминал TTY.

Для проверки, был ли Node.js запущен в контексте TTY, прочитайте свойство isTTY в process.stderr, process.stdout или process.stdin.

process.stdin

  • <Стрим>

Свойство process.stdin возвращает открытый для чтения стрим, эквивалентный или ассоциируемый с stdin (fd 0)

Пример:


process.stdin.setEncoding('utf8');

process.stdin.on('readable', () => {
  var chunk = process.stdin.read();
  if (chunk !== null) {
    process.stdout.write(`data: ${chunk}`);
  }
});

process.stdin.on('end', () => {
  process.stdout.write('end');
});

В качестве открытого для чтения стрима, process.stdin можно также использовать в «старом» режиме, совместимом со скриптами, записанными в Node.js до v0.10. См. совместимость стримов.

Примечание: в режиме «старых» стримов стрим stdin приостанавливается по умолчанию, так что можно вызвать process.stdin.resume() для чтения из него. Также следует обратить внимание на то, что вызов process.stdin.resume() сам по себе переключает стрим в «старый» режим.

process.stdout

  • <Стрим>

Свойство process.stdout возвращает открытый для записи стрим, эквивалентный или ассоциируемый с stdout (fd 1).

Пример:


console.log = (msg) => {
  process.stdout.write(`${msg}\n`);
};

Примечание: process.stderr и process.stdout отличаются от остальных стримов Node.js:

  1. Они не могут быть закрыты (выпадает end())
  2. Они никогда не генерируют событие ‘finish’
  3. Записи могут блокироваться, когда вывод перенаправляется на файл
    • Заметьте, что диски работают быстро и операционные системы обычно обращаются к кэшированию обратной записи, так что это очень редкое явление
  4. Записи на UNIX будут блокироваться по умолчанию, если вывод направляется на TTY (терминал)
  5. Функционал на Windows разный. Записи блокируются, если вывод не направляется на терминал TTY.

Для проверки, был ли Node.js запущен в контексте TTY, прочитайте свойство isTTY в process.stderr, process.stdout или process.stdin.

Терминалы TTY и process.stdout

Стримы process.stderr и process.stdout блокируются при выводе на терминалы TTY на OS X в качестве временного решения из-за малого размера буфера операционной системы в 1кБ. Это нужно для предотвращения чередования между stderr и stdout.

Для проверки, был ли Node.js запущен в контексте TTY, прочитайте свойство isTTY в process.stderr, process.stdout или process.stdin.


$ node -p "Boolean(process.stdin.isTTY)"
true
$ echo "foo" | node -p "Boolean(process.stdin.isTTY)"
false

$ node -p "Boolean(process.stdout.isTTY)"
true
$ node -p "Boolean(process.stdout.isTTY)" | cat
false

Cм. TTY документацию.

Примечание к процессу I/O

process.stdout и process.stderr существенно отличаются от других стримов Node.js:

  1. Они используются внутренне [console.log[] [console.error()][] соответственно.
  2. Они не могут быть закрыты (выпадает end()).
  3. Они никогда не генерируют событие ‘finish’.
  4. Записи могут быть синхронными в зависимости от того, какой стрим подключен и типа системы (Windows или Unix):
    • Файлы: синхронно на Windows и Linux
    • TTY (терминалы): асинхронно на Windows, синхронно на Unix
    • Пайпы (и сокеты): синхронно на Windows, асинхронно на Unix

Такое поведение можно объяснить сложившимися историческими причинами, так как их изменение создало бы обратную несовместимость, но некоторые пользователи их все еще используют.

Синхронные записи позволяют избежать проблем, таких, как неожиданно чередующиеся выводы в console.log() console.write(), или вовсе отсутствие вывода, если process.exit() вызывается перед завершением асинхронной записи. См. process.exit().

Предупреждение: Синхронные записи блокируют цикл событий, пока запись не завершится. В случае с выводом в файл это может происходить почти мгновенно, но при высокой нагрузке системы пайпы могут быть не прочитанными на стороне получателя, или медленными терминалами или файловой системой, что может спровоцировать слишком частую и длительную блокировку цикла событий с последующим серьезным негативным влиянием на производительность. При записи в интерактивную сессию терминала такой проблемы может и не быть, но нужно иметь в виду возможность ее появления при добавлении журнала в стримы выводов процесса.

Для проверки подключения стрима к содержимому TTY, проверьте свойство isTTY.

Пример:


$ node -p "Boolean(process.stdin.isTTY)"
true
$ echo "foo" | node -p "Boolean(process.stdin.isTTY)"
false
$ node -p "Boolean(process.stdout.isTTY)"
true
$ node -p "Boolean(process.stdout.isTTY)" | cat
false

См. документацию по TTY.

process.title

Добавлено в v0.1.104
  • <Строка>

Свойство process.title возвращает заголовок текущего процесса (например, возвращает текущее значение ps). Назначение нового значение в process.title изменяет текущее значение ps.

Примечание: когда назначается новое значение, различные платформы могут накладывать различные ограничения на максимальную длину заголовка. Как правило, такие ограничения сами по себе довольно ограничены. Например, на Linux и OS X process.title ограничивается размером бинарного имени плюс длина аргументов командной строки, так как установка process.title перезаписывает память argv процесса. Node.js v0.8 разрешается иметь более длинные строки для заголовков процессов посредством перезаписи памяти environ, но это потенциально небезопасно в некоторых случаях.

process.umask([mask])

Добавлено в v0.1.19
  • mask<число>

Метод process.umask() устанавливает или возвращает маску режима создания файлового процесса. Дочерний процесс наследует маску от родительского. Старая маска возвращается, если задан аргумент mask, в остальных случаях возвращается старая маска.


const newmask = 0o022;
const oldmask = process.umask(newmask);
console.log(
  `Changed umask from ${oldmask.toString(8)} to ${newmask.toString(8)}`
);

process.uptime()

Добавлено в v0.5.0
  • Возвращает число

Метод process.uptime() возвращает время в секундах, показывающее, как долго длится процесс Node.js.

process.version

Добавлено в v0.1.3
  • <Строка>

Свойство process.version возвращает версию Node.js в строке:


console.log(`Version: ${process.version}`);

process.versions

Добавлено в v0.2.0
  • <Объект>

Свойство process.versions возвращает объект, содержащий список строк с версиями Node.js и их зависимостями. Также process.versions.modules отображает текущую версию ABI, которая возрастает с изменениями API C++. Node.js отказывается загружать нативные модули, собранные для более старых значений modules.


console.log(process.versions);

будет генерировать вывод, похожий на:


{
  http_parser: '2.3.0',
  node: '1.1.1',
  v8: '4.1.0.14',
  uv: '1.3.0',
  zlib: '1.2.8',
  ares: '1.10.0-DEV',
  modules: '43',
  icu: '55.1',
  openssl: '1.0.1k',
  unicode: '8.0',
  cldr: '29.0',
  tz: '2016b' }

Коды завершения (Exit Codes)

Обычно Node.js завершается с кодом 0, если не выполняется никаких асинхронных операций. В остальных случаях используются следующие коды:

  • 1 Uncaught Fatal Exception – неперехваченное исключение, необработанное доменом или обработчиком события ‘uncaughtException’.
  • 2 – не используется (зарезервировано Bash для обозначения злоупотребления builtin)
  • 3 Internal JavaScript Parse Error – исходный код JavaScript, встроенный в bootstrap-процесс Node.js привел к ошибке парсинга. Очень редкий код, обычно попадается в процессе разработки самого Node.js.
  • 4 Internal JavaScript Evaluation Failure – исходному коду JavaScript, встроенному в bootstrap-процесс Node.js не удалось возвратить оцененное значение функции. Также очень редкий код, обычно попадается в процессе разработки самого Node.js.
  • 5 Fatal Error - фатальная ошибка в V8. Обычно сообщение выводится в stderr c префиксом FATAL_ERROR.
  • 6 Non-function Internal Exception Handler – неперехваченное исключение, но встроенная функция обработчика фатальных исключений каким-то образом не определилась как функция и не была вызвана.
  • 7 Internal Exception Handler Run-Time Failure – неперехваченное исключение, и встроенная функция обработчика фатальных исключений сама выдала ошибку при попытке его обработать. Случается, когда, к примеру, ‘uncaughtException’ или обработчик domain.on(‘error’) выдают ошибку.
  • 8 – не используется. В предыдущих версиях Node.js код завершения 8 иногда означал неперехваченное исключение.
  • 9 Invalid Argument – Либо была задана неизвестная опция, либо опция, требующая задания значения, была без значения.
  • 10 Internal JavaScript Run-Time Failure – исходный код JavaScript, встроенный в bootstrap-процесс Node.js, выдал ошибку, когда был вызвана bootstrap-функция. Очень редко попадается, чаще в процессе разработки самого Node.js.
  • 12 Invalid Debug Argument – опции --debug, --inspect и --debuf-brk были установлены, но выбранный номер порта был недопустимым либо недоступным.
  • >128 Signal Exits – если Node.js получает фатальный сигнал, такой, как SIGKILL или SIGHUP, то его код завершения будет 128 плюс значение кода сигнала. Это стандартная практика UNIX, так как коды завершения были определены как 7-битные целые числа, и завершение сигнала устанавливает старший бит, а потому содержит значение кода сигнала.