imap process not running

imap process not running

[Stefan Monnier]

[ I'm using the Emacs-CVS code, running on a GNU/Linux system using an
  IMAP/SSL connection using the `openssl' executable.  ]

Every once in a while, Gnus complains that the imap process is not running.
Usually it automatically restarts it behind my back, but occasionally it
burps instead.

The error I looks like the attached backtrace.


        Stefan


Debugger entered--Lisp error: (error <something like "imap process is not running">)
  process-send-string(#<process imap> "2442 UID FETCH 3355:3364 (UID RFC822.SIZE BODY BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])
\n")
  imap-send-command-1("2442 UID FETCH 3355:3364 (UID RFC822.SIZE BODY BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])")
  imap-send-command("UID FETCH 3355:3364 (UID RFC822.SIZE BODY BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])" nil)
  imap-send-command-wait("UID FETCH 3355:3364 (UID RFC822.SIZE BODY BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])")
  imap-fetch("3355:3364" "(UID RFC822.SIZE BODY BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])")
  nnimap-retrieve-headers-from-server((3355 . 3364) "diro" "diro")
  nnimap-retrieve-headers((3355 3356 3357 3358 3359 3360 3361 3362 3363 3364) "diro" "diro" nil)
  gnus-retrieve-headers((3355 3356 3357 3358 3359 3360 3361 3362 3363 3364) "nnimap+diro:diro" nil)
  gnus-agent-retrieve-headers((1312 1878 1902 1987 1988 2006 2168 2183 2779 3073 3159 3177 3184 3216 3276 3277 3282 3314 3323 3337 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364) "nnimap+diro:diro" nil)
  gnus-retrieve-headers((1312 1878 1902 1987 1988 2006 2168 2183 2779 3073 3159 3177 3184 3216 3276 3277 3282 3314 3323 3337 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364) "nnimap+diro:diro" nil)
  gnus-cache-retrieve-headers((1312 1878 1902 1987 1988 2006 2168 2183 2779 3073 3159 3177 3184 3216 3276 3277 3282 3314 3323 3337 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364) "nnimap+diro:diro" nil)
  gnus-retrieve-headers((1312 1878 1902 1987 1988 2006 2168 2183 2779 3073 3159 3177 3184 3216 3276 3277 3282 3314 3323 3337 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364) "nnimap+diro:diro" nil)
  gnus-fetch-headers((1312 1878 1902 1987 1988 2006 2168 2183 2779 3073 3159 3177 3184 3216 3276 3277 3282 3314 3323 3337 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364))
  gnus-select-newsgroup("nnimap+diro:diro" nil nil)
  gnus-summary-read-group-1("nnimap+diro:diro" nil t nil nil nil)
  gnus-summary-read-group("nnimap+diro:diro" nil t nil nil nil nil)
  gnus-group-read-group(nil t)
  gnus-group-select-group(nil)
  call-interactively(gnus-group-select-group)

Re: imap process not running

[Simon Josefsson]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> [ I'm using the Emacs-CVS code, running on a GNU/Linux system using an
>   IMAP/SSL connection using the `openssl' executable.  ]
>
> Every once in a while, Gnus complains that the imap process is not running.
> Usually it automatically restarts it behind my back, but occasionally it
> burps instead.
>
> The error I looks like the attached backtrace.
>
> Debugger entered--Lisp error: (error <something like "imap process is not running">)
>   process-send-string(#<process imap> "2442 UID FETCH 3355:3364 (UID RFC822.SIZE BODY BODY.PEEK[HEADER.FIELDS (Subject From Date Message-Id References In-Reply-To Xref To Newsgroups)])

It seems a call to process-status could be added to avoid the error.

However, Gnus/nnimap is supposed to check whether the server is alive
before attempting to use it, and that code call process-status.  So a
proper solution may be to track down what Gnus/nnimap operation it is
that call the backend unconditionally, and fix that, then the server
would be automatically re-opened as well.

I can try to find to work on adding the process-status call in
imap.el, to avoid the error, but depending on error propagation, it
may not be sufficient.  It will take a while, though, so if you or
someone want to look into this, that would be appreciated...

You might want to test with GnuTLS instead of OpenSSL too, tls.el
might be more reliable.

Thanks.