Re: [Evolution] [Fwd: Re: local mail spool still unaccessible with evo 3.4.4.-1]

[Pete Biggs <pete biggs org uk>]

> > > This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
> > > The overwriting error message was: Could not lock '/var/mail/<user>'
> >
> > And that is the root of all your problems.
> >
> > Check the ownership and permissions on the /var/mail/<user> file - it
> > should be owned by <user>. group should be "mail", and permissions
> > should be -rw-rw---- (i.e. rw by user and group, no world permissions).
>
> They are:
> -rw-rw---- 1 <user> mail 95684923 Oct 31 07:02 /var/mail/<user>
>
> and ls -ld /var/mail shows:
> drwxrwsr-x 2 root mail 4096 Oct 31 07:21 /var/mail/
>
> and <user> is in the group mail.

OK.  But the bottom line is that Evolution can't get a lock on your mail
spool file - if it can't get a lock, then it can't do anything with it.
If the permissions on the file are correct, then there must be some
other process holding a lock on it.  You need to find out which process
that is and why it is holding a lock.

To save you asking, use the lslk utility to list the current locks on
files.  If you can't find lslk (it's an old and unmaintained utility),
look in /proc/locks - the information in there is not user friendly, but
it contains lines such as:

1: POSIX  ADVISORY  WRITE 4953 08:11:17703846 1073741824 1073742335
                            ^           ^
                           PID         inode number

So you need to find the inode number of your mail spool file and see if
it's listed.

> I believe the UID has been the same for a long time. The problems
> started in end of June, probably with the upgrade from evo 3.4.2 to
> 3.4.3. 

This NOT an Evolution problem.  Evolution is doing the correct thing -
or at least the system is doing the correct thing by not allowing
Evolution access to a file that another process has a lock on.

> More strace output:
> [pid 16240] open("/var/mail/<user>", O_RDWR|O_LARGEFILE) = 33
> [pid 16240] open("/tmp/spool.camel.7JY6MW", O_RDWR|O_CREAT|O_EXCL|
> O_LARGEFILE, 0600) = 35
>
> (evolution:16230): camel-local-provider-WARNING **: Didn't get the next
> message where I expected (543185) got 0 instead
> [pid 16240] unlink("/tmp/spool.camel.7JY6MW") = 0
>
> (evolution:16230): camel-WARNING **: CamelSpoolStore::get_folder_sync()
> set its GError but then reported success
>
> (evolution:16230): camel-WARNING **: Error message was: Summary and
> folder mismatch, even after a sync

Some of these may be small bugs in Evo, but they are bugs that are only
being triggered by the underlying issue that Evo can not successfully
access the mail spool file, they are not bugs that are causing the
problem.  The "Summary and folder mismatch" error is probably being
caused by the fact that Evo updates the summary information in its local
store, then can't actually update the mail folder (i.e. spool file) to
match what has been summarised, and the next time it tries to do things
with the mail folder it gets confused.

P.