close(2) System Calls Manual close(2) NOM close - Fermer un descripteur de fichier BIBLIOTHEQUE Bibliotheque C standard (libc, -lc) SYNOPSIS #include int close(int fd); DESCRIPTION close() ferme le descripteur de fichier fd, de maniere a ce qu'il ne reference plus aucun fichier, et puisse etre reutilise. Tous les verrouillages (consultez fcntl(2)) sur le fichier qui lui etait associe, appartenant au processus, sont supprimes quel que soit le descripteur de fichier qui fut utilise pour obtenir le verrouillage. Cela a quelques consequences malheureuses il convient d'etre extremement prudent lors de l'utilisation de verrouillages d'enregistrements cooperatifs. Voir fcntl(2) pour une discussion sur les risques et consequences et sur l'utilisation (probablement preferable) des verrouillages de description de fichier ouvert. Si fd est le dernier descripteur de fichier qui se refere a une description de fichier ouvert sous-jacente (consultez open(2)), les ressources associees a la description de fichier ouvert sont liberees. Si le descripteur etait la derniere reference sur un fichier supprime avec unlink(2), le fichier est effectivement efface. VALEUR RENVOYEE Si elle reussit, la fonction close() renvoie zero. En cas d'erreur, elle renvoie -1 et elle remplit errno pour indiquer l'erreur. ERREURS EBADF Le descripteur de fichier fd est invalide. EINTR L'appel systeme close() a ete interrompu par un signal ; consultez signal(7). EIO Une erreur d'entree-sortie s'est produite. ENOSPC EDQUOT Sur NFS, ces erreurs ne sont en principe pas signalees lors de la premiere ecriture qui depasse l'espace de stockage disponible, mais lors d'un write(2), fsync(2) ou close() consecutif. See CAVEATS for a discussion of why close() should not be retried after an error. NORMES POSIX.1-2008. HISTORIQUE 4.3BSD, SVr4, POSIX.1-1988. NOTES L'attribut de descripteur de fichier close-on-exec peut etre utilise pour s'assurer qu'un descripteur de fichier est ferme automatiquement en cas de succes de execve(2) ; voir fcntl(2) pour des details. CAVEATS Une fermeture sans erreur ne garantit pas que les donnees ont ete vraiment ecrites sur le disque, car le noyau repousse les ecritures le plus tard possible. Il n'est pas frequent qu'un systeme de fichiers vide les tampons des la fermeture d'un flux. Si vous desirez vous assurer que les informations sont en surete sur le disque, utilisez fsync(2) (mais des considerations materielles entrent en jeu a ce moment). Processus multithreades et close() Il est probablement imprudent de fermer des descripteurs de fichier alors qu'ils peuvent peut-etre etre utilises par des appels systeme dans d'autres threads du meme processus. Puisqu'un descripteur de fichier peut etre reutilise, il y a des conditions de concurrence obscures qui peuvent provoquer des effets de bord non desires. Par ailleurs, imaginez un scenario ou deux threads effectuent plusieurs operations sur le meme descripteur de fichier : (1) Un thread est bloque dans un appel systeme E/S sur le descripteur de fichier. Par exemple, il essaie de write(2) dans un tube deja plein ou de read(2) depuis le socket d'un flux qui n'a pas de donnees disponibles actuellement. (2) Un autre thread ferme le descripteur de fichier. Dans cette situation, le comportement varie selon les systemes. Sur certains, quand le descripteur de fichier est ferme, l'appel systeme qui bloque renvoie immediatement une erreur. Sur Linux (et probablement d'autres systemes), le comportement est different : l'appel systeme E/S bloquant conserve une reference a la description du fichier ouvert sous-jacent et celle-ci garde la description ouverte jusqu'a ce que l'appel systeme E/S se termine (voir open(2) pour un point sur les descriptions de fichiers ouverts). Ainsi, l'appel systeme bloquant du premier thread peut se terminer avec succes apres le close() du deuxieme thread. Gerer les erreurs renvoyees par close() Un programmeur prudent verifiera le code de retour de close(), car il est possible qu'une erreur correspondant a un appel write(2) anterieur ne soit rapportee que lors du close() final. Ne pas verifier le code de retour lorsqu'un fichier est ferme peut conduire a une perte silencieuse de donnees. Cela est principalement vrai dans le cas de systemes de fichiers NFS, ou avec l'utilisation des quotas de disques. Remarquez cependant que la valeur de retour ne devrait etre utilisee que pour les diagnostics (a savoir pour prevenir une application qu'il peut rester des E/S en attente ou echouees) ou de correction (comme pour ecrire un fichier une ou plusieurs fois ou pour creer une sauvegarde). Reessayer close() apres un renvoi d'echec n'est pas la bonne maniere de faire, car il peut en resulter que le descripteur d'un fichier qui serait reutilise a partir d'un autre thread se ferme. Cela est possible car le noyau Linux abandonne toujours tot le descripteur de fichier lors d'une operation de fermeture, ce qui le libere pour etre reutilise ; les etapes de renvoi d'erreur telles que l'effacement des donnees sur le systeme de fichiers ou le peripherique arrivent plus tard dans l'operation de fermeture. Many other implementations similarly always close the file descriptor (except in the case of EBADF, meaning that the file descriptor was invalid) even if they subsequently report an error on return from close(). POSIX.1-2008 was silent on this point. Un programmeur prudent qui veut savoir les erreurs E/S doit faire preceder close() d'un appel fsync(2). The EINTR error is a somewhat special case. Regarding the EINTR error, POSIX.1-2008 said: If close() is interrupted by a signal that is to be caught, it shall return -1 with errno set to EINTR and the state of fd is unspecified. This permits the behavior that occurs on Linux and many other implementations, where, as with other errors that may be reported by close(), the file descriptor is guaranteed to be closed. However, it also permits another possibility: that the implementation returns an EINTR error and keeps the file descriptor open. (According to its documentation, HP-UX's close() does this.) The caller must then once more use close() 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, close() must not be called again after an EINTR error, and on at least one, close() must be called again. 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. VOIR AUSSI close_range(2), fcntl(2), fsync(2), open(2), shutdown(2), unlink(2), fclose(3) TRADUCTION La traduction francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot et Jean-Philippe MENGUAL Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.18 8 fevrier 2026 close(2)