Description of problem: I'm hearing reports that Evolution doesn't work very well with kernel-2.6.8-1.624; the behaviour of O_NONBLOCK has apparently changed, and this is showing up bugs in applications. Here's a grep for O_NONBLOCK within the evolution-2.0.2 source; appears to be confined to the camel code: [dmalcolm@cassandra evolution-2.0.2]$ grep -R O_NONBLOCK * camel/camel-tcp-stream-raw.c: fcntl (fd, F_SETFL, flags | O_NONBLOCK); camel/camel-tcp-stream-raw.c: data->value.non_blocking = flags & O_NONBLOCK ? TRUE : FALSE; camel/camel-tcp-stream-raw.c: set = data->value.non_blocking ? O_NONBLOCK : 0; camel/camel-tcp-stream-raw.c: flags = (flags & ~O_NONBLOCK) | set; camel/camel-tcp-stream-ssl.c: /* get O_NONBLOCK options */ camel/camel-tcp-stream-ssl.c: /* restore O_NONBLOCK options */ camel/camel-tcp-stream-ssl.c: /* get O_NONBLOCK options */ camel/camel-tcp-stream-ssl.c: /* restore O_NONBLOCK options */ camel/ChangeLog: O_NONBLOCK flag along with any previously set flags. camel/ChangeLog: * camel-filter-search.c (run_command): Don't set O_NONBLOCK on the camel/ChangeLog: O_NONBLOCK|prev_flags but we weren't, and so the pipe got camel/ChangeLog: O_RDONLY|O_NONBLOCK even tho we wanted to write to it). camel/camel-tcp-stream-openssl.c: fcntl (openssl->priv->sockfd, F_SETFL, flags | O_NONBLOCK); camel/camel-tcp-stream-openssl.c: fcntl (openssl->priv->sockfd, F_SETFL, flags | O_NONBLOCK); camel/camel-tcp-stream-openssl.c: fcntl (fd, F_SETFL, flags | O_NONBLOCK); camel/camel-tcp-stream-openssl.c: data->value.non_blocking = flags & O_NONBLOCK ? TRUE : FALSE; camel/camel-tcp-stream-openssl.c: set = data->value.non_blocking ? O_NONBLOCK : 0; camel/camel-tcp-stream-openssl.c: flags = (flags & ~O_NONBLOCK) | set; camel/camel-gpg-context.c: fcntl (gpg->passwd_fd, F_SETFL, flags | O_NONBLOCK); camel/camel-gpg-context.c: fcntl (gpg->stdin_fd, F_SETFL, flags | O_NONBLOCK); camel/camel-gpg-context.c: fcntl (gpg->stdout_fd, F_SETFL, flags | O_NONBLOCK); camel/camel-gpg-context.c: fcntl (gpg->stderr_fd, F_SETFL, flags | O_NONBLOCK); camel/camel-gpg-context.c: fcntl (gpg->status_fd, F_SETFL, flags | O_NONBLOCK); camel/camel-file-utils.c: fcntl (fd, F_SETFL, flags | O_NONBLOCK); camel/camel-file-utils.c: fcntl (fd, F_SETFL, flags | O_NONBLOCK); camel/ChangeLog.pre-1-4: connect right away, unset O_NONBLOCK so it doesn't mess us up
FWIW, a similar grep of the evolution-data-server source comes back empty
*** Bug 136075 has been marked as a duplicate of this bug. ***
Created attachment 105355 [details] Don't set O_NONBLOCK on regular files. I'm not sure entirely how O_NONBLOCK on regular files is supposed to work. Evo gets stuck in select(). It seems safest not to do it at all, rather than to try to make it work as expected. That's certainly the portable option. This fixes the case that actually bit me.
(Adding to FC4 target tracker for now)
Is this actually an issue anymore? My understanding is that setting O_NONBLOCK ought not to hurt when opening a regular file. From man 2 open: O_NONBLOCK or O_NDELAY When possible, the file is opened in non-blocking mode. Neither the open() nor any subsequent operations on the file descriptor which is returned will cause the calling process to wait. For the handling of FIFOs (named pipes), see also fifo(4). This mode need not have any effect on files other than FIFOs.
I think the standard theoretically allows for the behaviour which rawhide kernels once briefly exhibited. But there's just too much buggy software out there, perhaps encouraged by the man pages you quoted. I think that strictly speaking, it's still wrong -- but it's unlikely to become an issue because I don't think there'll be another attempt to make the kernel do whatever it was doing before for O_NONBLOCK files.
Thanks for the clarification. For now I'm going to close this as WONTFIX, so as to avoid diverging from upstream and to keep bugzilla a bit cleaner. Feel free to reopen if need be.