Что заставляет процесс Unix умереть с Поврежденным каналом?
Если Вы устанавливаете edit_headers опция к yes, можно отредактировать все заголовки почты перед отправкой, и можно установить собственное Date заголовок. Законное использование для этого выбирает Ваш собственный часовой пояс или Ваш собственный календарь.
Каждый сервер, через который проходит Ваша электронная почта, добавит a Received заголовок, содержащий дату, в которую это получило почту (или дата, в которую это соизволило для обработки его). Вы не можете фальсифицировать их, если Вы не имеете контроль над сервером. Более точно, с точки зрения получателя, заголовки являются надежным запуском с последней машины на пути, которому доверяет получатель.
Общей причиной почтовых задержек является greylisting. Может быть трудно предсказать, будет ли определенное электронное письмо greylisted, потому что решение частично основано на новейшей истории сервера с каждым отправителем. Однако не все серверы делают greylisting, и greylisting мог добавить к Вашему опозданию так или иначе.
Конечно, электронная почта может быть отложена из-за неправильного функционирования, обычного обслуживания или общей сетевой облупленности. Электронная почта была разработана, чтобы быть чрезвычайно надежной, но не обязательно быстро (когда она была изобретена, много сайтов не имело никакого постоянного сетевого соединения; электронная почта могла бы быть загружена и загружена один раз в день в некоторых местах). В наше время электронная почта не так надежна, как она раньше была, но это часто почти мгновенно. Задержка может произойти, но это необычно.
Если Вы не знаете, когда Ваше присвоение должно, спросите своего преподавателя.
Процесс получает SIGPIPE, когда он пытается записать в канал (названный или не) или сокет типа SOCK_STREAM, который не имеет читателя в запасе.
Это обычно хотело поведение. Типичный пример:
find . | head -n 1
Вы не хотите find продолжать работать однажды head завершился (и затем закрыл единственный дескриптор файла, открытый для чтения на том канале).
yes команда обычно полагается на тот сигнал завершиться.
yes | some-command
Запишет "y", пока некоторая-команда не завершится.
Обратите внимание, что это - не только когда команды выходят, это - когда все средство чтения закрыло их чтение fd к каналу. В:
yes | ( sleep 1; exec <&-; ps -fC yes)
1 2 1 0
Будет 1 (подоболочка), затем 2 (подоболочка + сон), затем 1 (подоболочка) затем 0 фарадеев, читающих из канала после того, как подоболочка explicitely закроет свой stdin, и именно тогда yes получит SIGPIPE.
Выше, большинство оболочек использует a pipe(2) в то время как ksh93 использование a socketpair(2), но поведение является тем же в том отношении.
Когда процесс игнорирует SIGPIPE, вызов системы письменности (обычно write, но мог быть pwrite, send, splice...) возвращается с a EPIPE ошибка. Таким образом, процессы, желающие обработать поврежденный канал вручную, обычно игнорировали бы SIGPIPE и принимали бы меры на ошибку EPIPE.
(6)
Запись, отказавшая, потому что нет никаких процессов, которые могли читать из канала.
Хотя, если Вы не копируете дескрипторы и ветвление, может только быть один процесс для запуска с: обычно канал имеет одно средство чтения и одно устройство записи, и когда один из них закрывает соединение, канал является более не существующим. При использовании именованного канала Вы, банка может установить многочисленные связи (в сериале) с ним, но каждый представляет новый канал в этом смысле. Таким образом, "канал" к потоку или процессу синонимичен с дескриптором файла.
От man 7 pipe:
Если все дескрипторы файлов, относящиеся к концу чтения канала, были закрыты, то запись (2) заставит сигнал SIGPIPE быть сгенерированным для обработки вызовов. Если обработка вызовов игнорирует этот сигнал, то запишите (2) сбои с ошибкой EPIPE.
Таким образом, "поврежденный канал" устройству записи, что EOF читателю.
Поврежденный канал происходит, когда процесс считывания выходит перед записью. Таким образом, я пошел бы с (6)
-
1Может быть несколько чтений процессов или записи в канал, и тот же процесс может читать и писать. Кроме того, это не о выходе, это о закрытии дескриптора файла. – Stéphane Chazelas 29.07.2013, 19:26