Управление файловыми дескрипторами

Системный вызов close всегда успешен в том смысле, что переданный файловый дескриптор после вызова функции уже никогда не является действительным. Однако close всё равно может вернуть ошибку, например, при сбое файловой системы. Но эта ошибка не очень полезна, потому что отсутствие ошибки не означает, что все кеши сброшены и предыдущие записи стали устойчивыми. Программы, которым требуются такие гарантии, должны открывать файлы с флагом O_SYNC или использовать fsync или fdatasync, а также, возможно, выполнять fsync для каталога, содержащего файл.

В отличие от идентификаторов процессов, которые переиспользуются постепенно, ядро всегда выделяет наименьший неиспользуемый файловый дескриптор при создании нового дескриптора. Это означает, что в многопоточной программе, которая постоянно открывает и закрывает файловые дескрипторы, дескрипторы переиспользуются очень быстро. Если закрытие дескриптора и другие операции с тем же дескриптором не синхронизированы (как правило, с помощью мьютекса), возникают состояния гонки, и операции ввода/вывода применяются к неверному файловому дескриптору.

Иногда возникает необходимость одновременно закрыть файловый дескриптор, в то время как другой поток может собираться использовать его в системном вызове. Чтобы обеспечить такую возможность, программе необходимо создать один специальный файловый дескриптор, для которого все операции ввода/вывода завершаются ошибкой. Один из способов достичь этого — использовать socketpair, закрыть один из дескрипторов и вызвать shutdown(fd, SHUTRDWR) для другого.

При одновременном закрытии дескриптора программа не вызывает close для дескриптора. Вместо этого программа использует dup2, чтобы заменить закрываемый дескриптор на фиктивный дескриптор, созданный ранее. Таким образом, ядро не будет переиспользовать дескриптор, но выполнит все остальные действия, связанные с закрытием дескриптора (например, если дескриптор ссылается на потоковый сокет, противоположная сторона будет уведомлена).

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

По умолчанию закрытие потокового сокета возвращает управление немедленно, а ядро пытается отправить данные в фоновом режиме. Это означает, что из пользовательского пространства невозможно реализовать точный учёт использования сетевых ресурсов.

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

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

Эти проблемы не связаны с состоянием TIME_WAIT, которое часто можно увидеть в выводе netstat. При необходимости ядро автоматически завершает такие сокеты.