I've started to see this recently trying to start evolution 2.7.4:
CalDAV Eplugin starting up ...
evolution-shell-Message: Killing old version of evolution-data-server...
(evolution-2.8:2055): camel-WARNING **: camel_exception_get_id called with NULL parameter.
(evolution-2.8:2055): camel-WARNING **: camel_exception_get_id called with NULL parameter.
(evolution-2.8:2055): Gtk-CRITICAL **: gtk_option_menu_set_history: assertion `GTK_IS_OPTION_MENU
(option_menu)' failed
(evolution-2.8:2055): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
The overwriting error message was: Error opening directory '/home/brian/.evolution/mail/imap/brian linux
interlinx bc ca/folders/INBOX': Too many open files
and then it craps out.
If I start with --offline and then just change to online mode once it's
started things are working.
Doing some straceing it appears that evolution opens a lot of pipes to
the point where more than 1024 fds are open and hence the EMFILE.
Here's a sample. This is just a very short snippet in time:
6967 pipe([78, 79]) = 0
6967 pipe([80, 81]) = 0
6967 fcntl64(80, F_GETFL) = 0 (flags O_RDONLY)
6967 fcntl64(80, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
6967 fcntl64(81, F_GETFL) = 0x1 (flags O_WRONLY)
6967 fcntl64(81, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
6967 write(23, "E", 1) = 1
6967 write(25, "E", 1) = 1
6967 gettimeofday({1152824998, 791548}, NULL) = 0
6967 pipe([82, 83]) = 0
6967 pipe([84, 85]) = 0
6967 fcntl64(84, F_GETFL) = 0 (flags O_RDONLY)
6967 fcntl64(84, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
6967 fcntl64(85, F_GETFL) = 0x1 (flags O_WRONLY)
6967 fcntl64(85, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
6967 write(23, "E", 1) = 1
6967 write(25, "E", 1) = 1
6967 close(63) = 0
6967 close(64) = 0
6967 close(65) = 0
6967 close(66) = 0
6967 write(19, "E", 1) = 1
6967 write(21, "E", 1) = 1
6967 select(35, [34], NULL, NULL, NULL <unfinished ...>
6958 close(46) = 0
6958 close(47) = 0
6958 close(61) = 0
6958 close(62) = 0
6958 pipe([46, 47]) = 0
6958 pipe([61, 62]) = 0
6958 fcntl64(61, F_GETFL) = 0 (flags O_RDONLY)
6958 fcntl64(61, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
6958 fcntl64(62, F_GETFL) = 0x1 (flags O_WRONLY)
6958 fcntl64(62, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
6958 read(18, "E", 1) = 1
6958 read(20, "E", 1) = 1
This pattern of:
pipe([fd1, fd2]) = 0
pipe([fd3, fd4]) = 0
fcntl64(fd3, F_GETFL) = 0 (flags O_RDONLY)
fcntl64(fd3, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
fcntl64(fd4, F_GETFL) = 0x1 (flags O_WRONLY)
fcntl64(fd4, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
seems to go on a _lot_ with no closing of the gobs and gobs of pipes
being created.
Ideas what's going on?
b.
--
My other computer is your Microsoft Windows server.
Brian J. Murrell
Attachment:
signature.asc
Description: This is a digitally signed message part