Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!us.feeder.erje.net!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Marko Rauhamaa Newsgroups: comp.lang.python Subject: Re: fork/exec & close file descriptors Date: Tue, 02 Jun 2015 23:05:45 +0300 Organization: A noiseless patient Spider Lines: 41 Message-ID: <87eglt7u5i.fsf@elektro.pacujo.net> References: <87pp5eksnc.fsf@universite-de-strasbourg.fr.invalid> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="b7cb1518d23ec19d482dcc9c31d30fdd"; logging-data="23043"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX187iiwdi9iZxiB0RxanBXud" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:V68/aTgK5HlQd+Ud5XJpaTmEvzs= sha1:qLeAntGVlwi5nd9VA8+L9hfwk9M= Xref: csiph.com comp.lang.python:91890 Alain Ketterlin : > The close(2) manpage has the following warning on my Linux system: > > | Not checking the return value of close() is a common but > | nevertheless serious programming error. It is quite possible that > | errors on a previous write(2) operation are first reported at the > | final close(). Not checking the return value when closing the file > | may lead to silent loss of data. This can especially be observed > | with NFS and with disk quota. > | > > (I haven't followed the thread, but if your problem is to make sure > fds are closed on exec, you may be better off using the... > close-on-exec flag. Or simply do the bookkeeping.) The quoted man page passage is a bit untenable. First, if close() fails, what's a poor program to do? Try again? How do you get rid of an obnoxious file descriptor? How would close-on-exec help? Would exec*() fail? What if an implicit close() fails on _exit(), will _exit() fail then? (The man page doesn't allow it.) The need to close all open file descriptors comes between fork() and exec*(). The kernel (module) does not see the close() system call unless the reference count drops to zero. Normally, those function calls between fork() and exec*() are therefore no-ops. However, there's no guarantee of that. So the parent process might get to call close() before the child that is about to call exec*(). Then, the parent would not get the error that the man page talks about. Instead, the error goes to the child, which has no reasonable way of dealing with the situation. I think having NFS et al postpone their I/O errors till close() is shifting the blame to the victim. Marko