.\" -*- coding: UTF-8 -*- .\" Copyright 1992, Drew Eckhardt .\" Copyright 2016, Michael Kerrisk .\" Copyright, the authors of the Linux man-pages project .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH close 2 "8 февраля 2026 г." "Linux man\-pages 6.18" .SH НАИМЕНОВАНИЕ close \- закрывает файловый дескриптор .SH БИБЛИОТЕКА Стандартная библиотека языка C (\fIlibc\fP,\ \fI\-lc\fP) .SH СИНТАКСИС .nf \fB#include \fP .P \fBint close(int \fP\fIfd\fP\fB);\fP .fi .SH ОПИСАНИЕ Программа \fBclose\fP() закрывает файловый дескриптор, так что он больше не ссылается ни на какой файл и может быть использован повторно. Любые блокировки записей (смотрите \fBfcntl\fP(2)), сохраненные в файле, с которым он был связан и которым владел процесс, удаляются независимо от файлового дескриптора, который использовался для получения блокировки. Это имеет некоторые печальные последствия и следует быть особенно осторожным при использовании рекомендуемой блокировки записей. Смотрите в \fBfcntl\fP(2) о рисках и последствиях, а также (вероятно, предпочтительных) блокировках дескрипторов открытых файлов. .P Если \fIfd\fP является последним файловым дескриптором, ссылающимся на базовый дескриптор открытого файла (смотрите \fBopen\fP(2), то ресурсы, связанные с дескриптором открытого файла, освобождаются; если файловый дескриптор был последней ссылкой на файл, удалённый с помощью \fBunlink\fP(2), то файл окончательно удаляется. .SH "ВОЗВРАЩАЕМОЕ ЗНАЧЕНИЕ" При успешном выполнении программы \fBclose\fP() возвращается 0. В случае ошибки возвращается \-1, а значение \fIerrno\fP указывает на ошибку. .SH ОШИБКИ .TP \fBEBADF\fP Значение \fIfd\fP не является допустимым дескриптором открытого файла. .TP \fBEINTR\fP .\" Though, it's in doubt whether this error can ever occur; see .\" https://lwn.net/Articles/576478/ "Returning EINTR from close()" Вызов \fBclose\fP() был прерван по сигналу; смотрите \fBsignal\fP(7). .TP \fBEIO\fP Произошла ошибка ввода\-вывода. .TP \fBENOSPC\fP .TQ \fBEDQUOT\fP В NFS об этих ошибках, обычно, не сообщается при первой записи, которая превысила доступное пространство памяти, а только при последующих операциях \fBwrite\fP(), \fBfsync\fP(2) или \fBclose\fP(). .P See CAVEATS for a discussion of why \fBclose\fP() should not be retried after an error. .SH СТАНДАРТЫ POSIX.1\-2008. .SH ИСТОРИЯ .\" SVr4 documents an additional ENOLINK error condition. 4.3BSD, SVr4, POSIX.1\-1988. .SH ПРИМЕЧАНИЯ Флаг файлового дескриптора close\-on\-exec можно использовать для гарантии того, что файловый дескриптор автоматически закроется при успешном выполнении \fBexecve\fP(2). Смотрите подробности в \fBfcntl\fP(2). .SH CAVEATS .\" Выполнение закрытия без ошибок не гарантирует, что данные были успешно записаны на диск, так как в ядре используется буферный кэш для отложенных записей. Как правило, файловые системы не записывают буферы при закрытии файла. Если требуется гарантировать физическую запись на используемый диск, то можно использовать \fBfsync\fP(2) (дальше всё будет зависеть от аппаратурных особенностей диска). .SS "Многопоточные процессы и close()" .\" Date: Tue, 4 Sep 2007 13:57:35 +0200 .\" From: Fredrik Noring .\" One such race involves signals and ERESTARTSYS. If a file descriptor .\" in use by a system call is closed and then reused by, e.g., an .\" independent open() in some unrelated thread, before the original system .\" call has restarted after ERESTARTSYS, the original system call will .\" later restart with the reused file descriptor. This is most likely a .\" serious programming error. Вероятно неблагоразумно закрывать дескрипторы файла, в то время как они могут использоваться системными вызовами других потоков того же процесса. Поскольку файловый дескриптор может использоваться повторно, то существуют некоторые неясные условия гонки, которые могут вызвать непреднамеренные побочные эффекты. .P Кроме того, рассмотрим следующий сценарий, в котором два потока выполняют операции с одним и тем же файловым дескриптором: .IP (1) 5 Один поток блокируется при системном вызове ввода\-вывода для файлового дескриптора. Например, он пытается выполнить \fBwrite\fP(2) (запись) в канал, который уже заполнен, или пытается выполнить \fBread\fP(2) (чтение) из потокового сокета, в котором в данный момент нет доступных данных. .IP (2) Другой поток закрывает файловый дескриптор. .P Поведение в этой ситуации различается в разных системах. В некоторых системах, когда файловый дескриптор закрыт, системный вызов блокировки немедленно возвращается с ошибкой. .P .\" 'struct file' in kernel-speak .\" В Linux (и, возможно, в некоторых других системах) поведение иное: системный вызов блокировки ввода\-вывода содержит ссылку на дескриптор базового открытого файла и эта ссылка сохраняет дескриптор открытым до завершения системного вызова ввода\-вывода (смотрите \fBopen\fP(2) для обсуждения открытого файлового дескриптора). Таким образом, блокирующий системный вызов в первом потоке может успешно завершиться после \fBclose\fP() во втором потоке. .SS "Обработка ошибки, возвращённой close()" Аккуратный программист всегда проверяет возвращаемое \fBclose\fP() значение, так как очень вероятно, что об ошибках предыдущей операции \fBwrite\fP(2) будет сообщено только при последнем вызове \fBclose\fP(), который освобождает дескриптор открытого файла. Невыполнение проверки возвращаемого значение при закрытии файла может привести к \fIsilent\fP (неучтённой) потере данных. Это особенно часто встречается с NFS и с дисковыми квотами. .P Однако заметим, что возвращаемая ошибка должна использоваться только для диагностики (т. е. предупреждать приложение, что, возможно, есть незаконченные операции ввода\-вывода или произошла ошибка ввода\-вывода) или для исправления (например, повторной записи файла, или для создания резервной копии). .P .\" The file descriptor is released early in close(); .\" close() ==> __close_fd(): .\" __put_unused_fd() ==> __clear_open_fd() .\" return filp_close(file, files); .\" .\" The errors are returned by filp_close() after the FD has been .\" cleared for re-use. .\" filp_close() Повторный вызов \fBclose\fP() после получения ошибки делать не стоит, так как это может привести к закрытию повторно использованного файлового дескриптора другого потока. Это может произойти из\-за того, что ядро Linux \fIalways\fP освобождает файловый дескриптор в самом начале операции закрытия, делая его доступным для повторного использования. Шаги, которые могут вернуть ошибку, такие как сброс данных в файловую систему или в устройство, происходят только после операции закрытия. .P .\" FreeBSD documents this explicitly. From the look of the source code .\" SVR4, ancient SunOS, later Solaris, and AIX all do this. Many other implementations similarly always close the file descriptor (except in the case of \fBEBADF\fP, meaning that the file descriptor was invalid) even if they subsequently report an error on return from \fBclose\fP(). POSIX.1\-2008 was silent on this point. .P Аккуратный программист, который хочет узнать об ошибках ввода\-вывода, перед вызовом \fBclose\fP() вызовет \fBfsync\fP(2). .P The \fBEINTR\fP error is a somewhat special case. Regarding the \fBEINTR\fP error, POSIX.1\-2008 said: .P .RS If \fBclose\fP() is interrupted by a signal that is to be caught, it shall return \-1 with \fIerrno\fP set to \fBEINTR\fP and the state of \fIfd\fP is unspecified. .RE .P This permits the behavior that occurs on Linux and many other implementations, where, as with other errors that may be reported by \fBclose\fP(), the file descriptor is guaranteed to be closed. However, it also permits another possibility: that the implementation returns an \fBEINTR\fP error and keeps the file descriptor open. (According to its documentation, HP\-UX's \fBclose\fP() does this.) The caller must then once more use \fBclose\fP() to close the file descriptor, to avoid file descriptor leaks. This divergence in implementation behaviors provides a difficult hurdle for portable applications, since on many implementations, \fBclose\fP() must not be called again after an \fBEINTR\fP error, and on at least one, \fBclose\fP() must be called again. .P POSIX.1\-2024 standardized the behavior of HP\-UX, making Linux and many other implementations non\-conforming. There are no plans to change the behavior on Linux. .SH "СМОТРИТЕ ТАКЖЕ" \fBclose_range\fP(2), \fBfcntl\fP(2), \fBfsync\fP(2), \fBopen\fP(2), \fBshutdown\fP(2), \fBunlink\fP(2), \fBfclose\fP(3) .PP .SH ПЕРЕВОД Русский перевод этой страницы руководства разработал(и) Dmitry Bolkhovskikh , Yuri Kozlov и Aleksandr Felda . .PP Этот перевод является свободной программной документацией; он распространяется на условиях общедоступной лицензии GNU (GNU General Public License - GPL, .UR https://www.gnu.org/licenses/gpl-3.0.html .UE версии 3 или более поздней) в отношении авторского права, но БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ. .PP Если вы обнаружите какие-либо ошибки в переводе этой страницы руководства, пожалуйста, сообщите об этом разработчику(ам) по его(их) адресу(ам) электронной почты или по адресу .MT debian-l10n-russian@lists.debian.org списка рассылки русских переводчиков .ME .