Re: [Evolution] evolution taking 5+ minutes to shut down
- From: Jason 'vanRijn' Kasper <vR movingparts net>
- To: Not Zed <notzed ximian com>
- Cc: evolution lists ximian com
- Subject: Re: [Evolution] evolution taking 5+ minutes to shut down
- Date: 12 Jun 2003 14:56:23 -0400
On Wed, 2003-06-11 at 22:29, Not Zed wrote:
I suggest filing a bug (bugzilla.ximian.com), well, after trying the
suggestion at the end of this text.
Yes, I'll wait a bit until I see if I can reproduce it reliably.
Curious, does X totally lock up, or just run like a pig?
well, it runs enough like a pig that although I'm able to move my mouse
cursor, X 4.3's mouse animation stops, and X itself stops handling focus
changes and all input until the "now closing down" window goes away.
Other info that will help (if you dont supply it we'll ask anyway :)
- the CAMEL_VERBOSE_DEBUG=1 log as suggested by Ettore (run
"CAMEL_VERBISE_DEBUG=1 evolution-1.3" in a terminal)
I will henceforth run evo this way. =:) I'll also log everything to a
file so that if it does happen, hopefully something useful will show up.
- run evolution-1.3 in gdb. Do some stuff, and quit so that things
start going haywire. ctrl-c in gdb (if you can't ... that could be a
problem, try running it from a virtual console perhaps), and run 'thread
apply all bt' - this will show what code is running.
well, again, when this happens, I can't do squat. Even though I start
evolution with "nice evolution", I can't even switch to a VC until evo's
done with its thing.
syncing maildir folders should be almost instantaneous, so something's
getting screwed. my guess is its the dreaded indexer-goes-nuts bug. it
generates massive temporary files that then shrink back to normal size -
if it doesn't fill up the disk first. could try rm'ing any *.ibex*
files in your folders, and restart.
well, I just checked the sizes on these and since I keep my Maildir
outside of $HOME/evolution, the only $HOME/evolution/**/*.ibex* files
that I can see are tiny.
However, what you said makes perfect sense. Like I said, my hard drive
goes absolutely bonkers when this happens, and from what I've seen in
the past (when copying large files/moving files/removing files, etc.)
with XFS, it seems that XFS takes up massive amounts of CPU to do
massive amounts of disk work--to the point that the system becomes
unusable until it's done. Now, this was a while ago and I'm hoping that
XFS 1.2 has improved, but it just seems like this could be pointing to
XFS in some way (as a side-result of some fonky evo behavior).
Now, there's a couple of things that I can think of, given the above,
that might lend itself to this lock-up. I normally don't "auto-expunge
trash on exit" with my $HOME/Maildir, which means, that I may have more
than several hundred entries in that vfolder at any given point in
time. It would seem that this might be problematic. What do you think?
Also, I currently have bogofilter/procmail sending spam into a
$HOME/Maildir/Spam Maildir, and though evolution doesn't see this
automatically get updated when procmail puts mail there (while evo is
running), I'm wondering if it realizes that there's a whole bunch of
mail there since last time it looked (when it's going to shut down) and
tries to deal with them there? Like maybe it's updating the default,
un-deletable "Unmatched" VFolder, since the Spam Maildir is inside the
top-level Maildir that evo knows about?
Thanks for the reply, notzed. =:)
On Wed, 2003-06-11 at 22:17, Jason 'vanRijn' Kasper wrote:
As a prelude, I am running evo 1.3.92 on debian sid, on a P4 1.8G laptop
with 1G of RAM. I keep all of my mail in Maildir format in ~/Maildir,
which takes up 86M, and evolution of course has its own directory in
~/evolution, which takes up 18M. All of my filesystems are
XFS--recently upgraded to kernel-space 1.2. All your base are... no,
nevermind.
I typically suspend my laptop at the end of the work day and resume it
at home, then suspend and repeat the next day, etc. Thus, I typically
leave eveolution running for days and days at a time.
As of late, I've been noticing that evolution takes a REALLY long time
to shut down, and while it does so, X locks up until it is done. I
notice that my hard drive is spinning constantly and at gkrellm's last
update, it shows my hda traffic at 2.6M/s+.
I just rebooted yesterday for a new kernel and restarted evolution, then
suspended at end of day, resumed last night, and closed evolution this
morning (note: evolution was running for less than 24 hours this time).
It took 7 minutes between when evolution popped up it's "evolution is
closing" dialog window and when I finally was allowed to use my computer
again.
My questions:
- what in blazes is evolution doing between when it pops up its
"evolution is closing" window and when it's done?
- what in my described-above system could be contributing to this 7
minutes that I get to sit quietly and wait for the "now closing" window
to go away?
- is anyone else seeing this???
- even though I've started evo with "nice evolution", my system locks
completely and I'm unable to even switch to a VC. Is there any way I
can debug this thing??
TIA.
_______________________________________________
evolution maillist - evolution lists ximian com
http://lists.ximian.com/mailman/listinfo/evolution
--
,-----------------------------------------------------------------//
| Jason 'vanRijn' Kasper :: Numbers 6:22-26
`
| All brontosauruses are thin at one end, much MUCH thicker
| in the middle, and then thin again at the far end. That is
| the theory that I have and which is mine, and what it is too.
,
| bash$ :(){ :|:&};:
`----------------------//
__________________________________________________________________________
Disclaimer: This e-mail message is intended only for the personal use of
the recipient(s) named above. If you are not an intended recipient, you
may not review, copy or distribute this message. If you have received this
communication in error, please notify us immediately by e-mail and delete
the original message.
This e-mail expresses views only of the sender, which are not to be
attributed to Rite Aid Corporation and may not be copied or distributed
without this statement.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]