GNOME Bugzilla – Bug 206335
may want to reconsider locking mechanisms
Last modified: 2013-09-10 14:02:48 UTC
Distribution: Red Hat Linux release 7.1 (Seawolf) System: Linux 2.4.2-2 i686 unknown C library: glibc-2.2.2-10 C compiler: 2.96 glib: 1.2.9 GTK+: 1.2.9 ORBit: ORBit 0.5.7 gnome-libs: gnome-libs 1.2.8 libxml: 1.8.10 gnome-print: gnome-print-0.25-9 gnome-core: gnome-core 1.2.4 Did not find similar problem in BugZilla search I tried to add my local user id as an additional mail account under evolution. I started with my @home account and that works AOK. I have the default folders *only* under "My Evolution". After adding the additional account as type 'Standard Unix mailbox file' Path:/var/spool/rcavey When I try to send and receive mail... A popup window displays the exact message: Error while performing operation: Could not Lock '/var/spool/mail/rcavey' The permission look correct for /var/spool/mail/rcavey. I have accessed the rcavey account mail with Pine and Kmail previously.
the problem is not that it can't read the mailbox, the problem is that it can't *lock* the mailbox. In order to lock a mailbox, the program needs access to create files in that directory. I bet that KMail doesn't lock the spool file when it goes to read it and I believe that Pine uses an external program.
someone else had this problem last night and it was discovered that the problem was the permissions on his /var/spool/mail directory didn't give read access to all users. chmod a+r /var/spool/mail might work for you also.
This doesn't make sense. The lock daemon runs as setgid/setuid, it doesn't need ot read the directory.
The permissions were and still are correct. I think the other person was modifying permissions to try and solve the probelm?? I have not touched the permissions under /var/spool EVER. [rcavey@kickass spool]$ pwd /var/spool [rcavey@kickass spool]$ ls -la | grep mail drwxrwxr-x 2 root mail 1024 Aug 6 12:00 mail drwxr-xr-x 2 root mail 1024 Aug 6 12:00 mqueue [rcavey@kickass spool]$ pwd /var/spool [rcavey@kickass spool]$ ls -la <snip> drwxr-xr-x 13 root root 1024 May 22 22:16 . drwxr-xr-x 23 root root 1024 Jul 29 23:31 .. <snip> drwxrwxr-x 2 root mail 1024 Aug 6 12:00 mail <snip> [rcavey@kickass spool]$ cd mail [rcavey@kickass mail]$ ls -la total 5 drwxrwxr-x 2 root mail 1024 Aug 6 12:00 . drwxr-xr-x 13 root root 1024 May 22 22:16 .. -rw------- 1 rcavey mail 2201 Aug 6 12:00 rcavey -rw------- 1 root root 0 Aug 6 10:24 root
*** bug 205342 has been marked as a duplicate of this bug. ***
*** bug 206198 has been marked as a duplicate of this bug. ***
*** bug 205824 has been marked as a duplicate of this bug. ***
Check the permissions on /usr/sbin/camel-lock-helper: Mine are now: -rwxr-sr-x 1 root mail 58968 Aug 1 03:04 camel-lock-helper Prior to that, it was owned by root.root. This is my fix, <stddisclaimer>: $ cd /usr/sbin #(note that is sbin, not bin) $ ls -la camel-lock-helper # Note if owner and group are root.root, if so, proceed: $ su root Password: ************ (root)$ chown root.mail camel-lock-helper (root)$ chmod g+s camel-lock-helper (root)$ exit $ ls -la camel-lock-helper The output for the ls should now be as listed at the top of this comment. Launch evolution and see if send/get mail now works. Only bummer I have had with evolution is the wiping out of my saved POP3 contents when I upgraded to .12 from .08 dunk
*** bug 207604 has been marked as a duplicate of this bug. ***
does this work now?
The problem was fixed with dunk's changes although when I upgraded the evolution package via red-carpet I have to make the change manually again. Should a new bug be submitted for someone to make the change to the installer scripts? Thanks, Bob
Can we get a confirmation that this fix will be included in the latest RPMs / RedCarpet updates? Would be nice to finally close this bug. Off Topic: Finding if a bug exists that is similar to one's problem is a bit hard for new persons to follow. The search form is complex and needs a bit of understanding in bug management and the bugzilla system. Would it be possible to put a very simple 'Knowledge Base' front end onto bugzilla? Ideally, it would be a form with only one text entry. Typing in [evolution mail could not lock] would give a quick list of bugs that match the query in either the short summary or long description. Maybe just exporting out the bugzilla db and using htdig to index it would take care of this problem. Email me directly, or point me in the right direction as I know this is off topic. thanks dunk
packagers: we need for camel-lock-helper to (in most cases) belong to group 'mail' and have the setgid bit set. The makefile in camel/ should chown/chgrp and chmod the file correctly with the detected system settings but for some reason it's not being installed with those settings.
Re-assignign to jpr, as he is the main packager ATM.
*** bug 208995 has been marked as a duplicate of this bug. ***
*** bug 209576 has been marked as a duplicate of this bug. ***
This should be working in the snapshots now for RedHat, still need to figure out why it doesn't work for deb packages yet.
As of newest nightly build available from RedCarpet, evolution now will try to get the local mail. It starts downloading the messages it says from /var/spool/mail/leggett but after getting around 95-100 messages either the mailer crashes, or evolution crashes. Now when I try to view /var/spool/mail/leggett (after the first crash), it is empty, yet everytime evolution tries to get local mail it says its getting mail from /var/spool/mail/leggett and tries to download the same messages and crashes again. Where is evolution keeping the messages from the local spool since it can't be getting it from the actual spool?
Ti: It Stores them in ~/evolution/local/Inbox/movemail.n Cna you please obtain a backtrace of where this crashes, and submit another bug report.
With 0.14, I still have this problem, as described in bug 209576. As with 0.13 and 0.12, my workaround of rebuilding evolution from source solves the problem. Perhaps the locking configuration that ./configure detects is different from the one built into the RPM? (shouldn't it be detected at run-time or RPM install time?) Here's the data output by ./configure of 0.14: Mail Directory: /var/spool/mail, writable by group mail LDAP support: no NNTP support: no Pilot conduits: no Kerberos 4/5: no/no SSL support: yes S/MIME support: no Use movemail: no Dot Locking: yes File Locking: fcntl Gtk-doc: no
*** bug 208781 has been marked as a duplicate of this bug. ***
As of 0.15, the "Could not lock" diagnostic is gone, but Evolution still will not read the mail spool. The same workaround as before (rebuilding evolution from source) fixes the problem.
It wont read the mail? What does it do then?
In 0.15, instead of the locking diagnostic, I just get an empty inbox folder showing. btw, I've confirmed that I can use the RPM's rather than recompiling provided I change the permissions and ownership of /usr/sbin/camel-lock-helper. The RPM leaves them as root.root 755. changing them to root.mail 2755 makes everything work.
this should probably be reported to the packagers
jeff: that's why jp is on the cc list.
My best guess is that this is a dest dir issue. Peter?
*** bug 214039 has been marked as a duplicate of this bug. ***
Reassigning to peter the packaging wizard because i'm at a loss for debian.
*** bug 214495 has been marked as a duplicate of this bug. ***
/me pokes peter
Yes? The plan is still to fix this after I get the new tarballs.
*** bug 214834 has been marked as a duplicate of this bug. ***
Problem still occurs with RC1, same as before
Just to confirm the problem is still in RC 1 in debian.
Just marking this up so we don't forget about it.
Debian packages or Ximian packages?
Bug present in Ximian .deb packages
The other alternative is we always install it setuid to 'root' and let the code work out what to do. If the packaging will never get it right anyway ...
Guys, shouldn't you really be using fcntl() instead of lockfiles anyhow, at least on some platforms - I think this is the Red Hat standard. Lock files are inherently buggy; either they are unreliable, or you can get stale locks. Moreover they require setuid/setgid mess that people have trouble getting right. GConf tried using lockfiles forever, it didn't work, it uses fcntl() now, and all the problems people were having have gone away. Though I'm guessing in this case all mail apps on the system need to be using the same scheme - so you may have to support both. On Red Hat I don't think any of the MUAs we ship will pay the least bit of attention to lock files, AFAIK they are all patched to use fcntl().
As of today's snap, this still hasnt been fixed
*** bug 215639 has been marked as a duplicate of this bug. ***
*** bug 215627 has been marked as a duplicate of this bug. ***
*** bug 215870 has been marked as a duplicate of this bug. ***
OK, guys, clearly this is intended to work by having the camel-lock-helper program get the lock. According to fejj@ximian.com, this program is supposed to be setgid to group mail and the program is built that way, but something is going wrong during packaging. So, either you have a bug in the way Ximian packages are built, so you can either fix that (which I know can be done because mutt uses the exact same trick of having a separate sgid mail program named mutt_dotlock), or you can simply work around the bug, on Debian, by adding a couple of lines to the postinst script to set the program's group and permissions.
The final packages do this correctly on all platforms. The RC2 packages on debian potato should already do this right. Is this not the case? (RC2 != snapshots).
*** bug 215895 has been marked as a duplicate of this bug. ***
OK, moving this to 1.2 as a 'we may want to reconsider how we do locking' bug. Thanks for the work, Dan.
We're not changing the way we do locking. This is a packaging issue entirely.
presumed "fixed" since the packages are now doing this correctly
Problem still exists in 1.0 debian packages. I just did a reinstall yesterday and the problem reoccured. I tested this with RC2 and it worked fine. With the RC2 install hopwever, I'm not sure if I had removed the fixed RC1 camel-lock-helper file or not. I couldn't say for sure if the debian install would reset the ownership and setgid or not.
*** bug 215872 has been marked as a duplicate of this bug. ***
*** bug 218652 has been marked as a duplicate of this bug. ***
hmmm, we default to both dot-locking *and* fcntl locking, right? that should be interoperable with damn near everything...
Havoc - We do do both, and both need to be done. Many nfs servers dont do fcntl for example, and mail on nfs is pretty damn common. elm has been doing it successfully for years, so its not that the idea is inherently undoable. Its also been working sucessfully in evolution for years. Jeff - this is ENTIRELY a packaging problem. The only rememdy i can think of is to force camel-lock-helper to always be set-uid root on all installs, which of course i'd rather not do. Ettore, its upto you. either we do nothing or change it to setuid root always - there's no other alternative. package managers can't deal with permissions changing during install, and the package building machines aren't setup right (actually can't be) for all possible run-time situations.
Just some random thoughts off the top of my head: Can we piggy back on either the Pine or Elm suid program? If the camel-lock program fails, at least the user should get a more informitive error message w/ link to this bug and prehaps the name of a script (that is installed w/ evolution) to fix the suid problem automatically. At the very least, a more descriptive error message would be wonderful. I spent a few hours searching w/ strace to find the camel-lock program. Off-Topic: Any chance of interoperating w/ Pine or elm and their mailboxes? I really don't like how Evol likes to suck all the email out of the inbox. I still would like to be able to telnet in and check/read/reply to email w/ pine or mutt. dunk
you can always make Evolution use the spool provider. anyways, this is solved by the packaging people (or so I am told).