Quote:
Originally Posted by walter.80@osu.edu Sorry, but the ~/.evolution/log directory does not exist. I went ahead and made the directory just it must be made manually. I am using an Ubuntu package for evolution. Perhaps the logging needs to be enable in Evolution? Sorry for the amateur questions/comments. M< |
OK, now I do have problems.
1. I tried to sync my PalmIII through evolution to my zimbra address book and zimbra calendar. My Palm is using a serial connected cradle. I am using gpilot. In both the addressbook and datebook cases the the hard drive starts "going crazy" and the palm eventually looses its connection with the desktop. It seems that there is a memory leak somewhere (if that is the right term). Here is a snippet from /var/log/messages:
Apr 2 16:01:19 oak kernel: [8035802.295265] printk: 86 messages suppressed.
Apr 2 16:01:20 oak kernel: [8035802.295272] tail invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Apr 2 16:01:20 oak kernel: [8035802.295274]
Apr 2 16:01:20 oak kernel: [8035802.295275] Call Trace:
Apr 2 16:01:20 oak kernel: [8035802.295302] [out_of_memory+694/816] out_of_memory+0x2b6/0x330
Apr 2 16:01:20 oak kernel: [8035802.295311] [__alloc_pages+760/848] __alloc_pages+0x2f8/0x350
Apr 2 16:01:20 oak kernel: [8035802.295321] [__do_page_cache_readahead+263/672] __do_page_cache_readahead+0x107/0x2a0
Apr 2 16:01:20 oak kernel: [8035802.295331] [io_schedule+40/64] io_schedule+0x28/0x40
Apr 2 16:01:20 oak kernel: [8035802.295337] [__wait_on_bit_lock+101/128] __wait_on_bit_lock+0x65/0x80
Apr 2 16:01:20 oak kernel: [8035802.295344] [__lock_page+95/112] __lock_page+0x5f/0x70
Apr 2 16:01:20 oak kernel: [8035802.295352] [filemap_nopage+568/752] filemap_nopage+0x238/0x2f0
Apr 2 16:01:20 oak kernel: [8035802.295361] [__handle_mm_fault+452/2912] __handle_mm_fault+0x1c4/0xb60
Apr 2 16:01:20 oak kernel: [8035802.295375] [do_page_fault+508/2160] do_page_fault+0x1fc/0x870
Apr 2 16:01:20 oak kernel: [8035802.295389] [sys_newfstat+46/80] sys_newfstat+0x2e/0x50
Apr 2 16:01:20 oak kernel: [8035802.295398] [error_exit+0/132] error_exit+0x0/0x84
Apr 2 16:01:20 oak kernel: [8035802.295411]
Apr 2 16:01:20 oak kernel: [8035802.295412] Mem-info:
Apr 2 16:01:20 oak kernel: [8035802.295414] Node 0 DMA per-cpu:
Apr 2 16:01:20 oak kernel: [8035802.295417] CPU 0: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
Apr 2 16:01:20 oak kernel: [8035802.295419] CPU 1: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
Apr 2 16:01:21 oak kernel: [8035802.295422] CPU 2: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
Apr 2 16:01:21 oak kernel: [8035802.295425] CPU 3: Hot: hi: 0, btch: 1 usd: 0 Cold: hi: 0, btch: 1 usd: 0
Apr 2 16:01:21 oak kernel: [8035802.295427] Node 0 DMA32 per-cpu:
Apr 2 16:01:21 oak kernel: [8035802.295429] CPU 0: Hot: hi: 186, btch: 31 usd: 33 Cold: hi: 62, btch: 15 usd: 48
Apr 2 16:01:21 oak kernel: [8035802.295432] CPU 1: Hot: hi: 186, btch: 31 usd: 15 Cold: hi: 62, btch: 15 usd: 14
Apr 2 16:01:21 oak kernel: [8035802.295435] CPU 2: Hot: hi: 186, btch: 31 usd: 5 Cold: hi: 62, btch: 15 usd: 58
Apr 2 16:01:21 oak kernel: [8035802.295438] CPU 3: Hot: hi: 186, btch: 31 usd: 31 Cold: hi: 62, btch: 15 usd: 33
Apr 2 16:01:21 oak kernel: [8035802.295442] Active:240426 inactive:245125 dirty:0 writeback:0 unstable:0
Apr 2 16:01:21 oak kernel: [8035802.295443] free:3429 slab:9924 mapped:49 pagetables:7453 bounce:0
Apr 2 16:01:21 oak kernel: [8035802.295445] Node 0 DMA free:8024kB min:28kB low:32kB high:40kB active:2300kB inactive:1336kB present:11216kB pages_scanned:41540 all_unreclaimable? yes
Apr 2 16:01:21 oak kernel: [8035802.295450] lowmem_reserve[]: 0 2003 2003
Apr 2 16:01:21 oak kernel: [8035802.295452] Node 0 DMA32 free:5692kB min:5712kB low:7140kB high:8568kB active:959404kB inactive:979164kB present:2052080kB pages_scanned:4557187 all_unreclaimable? yes
Apr 2 16:01:21 oak kernel: [8035802.295457] lowmem_reserve[]: 0 0 0
Apr 2 16:01:21 oak kernel: [8035802.295460] Node 0 DMA: 0*4kB 1*8kB 1*16kB 0*32kB 1*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 1*4096kB = 8024kB
Apr 2 16:01:21 oak kernel: [8035802.295467] Node 0 DMA32: 31*4kB 21*8kB 4*16kB 1*32kB 0*64kB 1*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 1*4096kB = 5636kB
Apr 2 16:01:21 oak kernel: [8035802.295476] Swap cache: add 2496262, delete 2496266, find 22783301/23021205, race 2+2188
Apr 2 16:01:21 oak kernel: [8035802.295478] Free swap = 0kB
Apr 2 16:01:21 oak kernel: [8035802.295479] Total swap = 506036kB
Apr 2 16:01:21 oak kernel: [8035802.295481] Free swap: 0kB
Apr 2 16:01:21 oak kernel: [8035802.308959] 524227 pages of RAM
Apr 2 16:01:21 oak kernel: [8035802.308963] 8567 reserved pages
Apr 2 16:01:21 oak kernel: [8035802.308964] 11695 pages shared
Apr 2 16:01:21 oak kernel: [8035802.308966] 4 pages swap cached
Apr 2 16:01:21 oak kernel: [8035802.309173] dd invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0
Apr 2 16:01:21 oak kernel: [8035802.309175]
.
.
.
I ran evolution with "evolution --debug ~/.evolution/log/log1.txt" and got only the following:
CalDAV Eplugin starting up ...
evolution-shell-Message: Killing old version of evolution-data-server...
(evolution:3806): e-data-server-DEBUG: Loading categories from "/home/walter/.evolution/categories.xml"
(evolution:3806): e-data-server-DEBUG: Loaded 30 categories
calendar-gui-Message: Check if default client matches (1171470022.9211.12@oak 1171470022.9211.12@oak)
After the system "recovers itself." I see that some events did make it into the calendar. They are not all there and the recurring events are not correct. (At least the monthly recurring events become weekly recurring events.)
When I tried to sync the address book, nothing got transferred. I ended up with the similar hard drive/memory problems. I did not have the evolution --debug activated when attempting to sync the address book.
If anyone wants me to debug the connector, I would need explicit instructions. I do not know now to run trace or other debugging programs.
I also tried copying a large (local) evolution calendar to a zimbra calendar. I did this by right clicking on the local calendar and selecting copy. It seems to just hang after a while. I do not think that I have the same memory problem as above. I have to kill evolution after this. I did not have evolution --debug running at the time. I actually let one of these copy exercises run overnight. As with the Palm sync attempts, some events were transferred ... but only a fraction of them. I have done a drag'n'drop of single events and that seemed to work fine.
I would really like to move everything to zimbra and be able to sync directly. I am thinking of just importing the ics file in zimbra. However, I think that I will have the same problem with recurring events and I am not sure this will solve my sync problems. I am wondering if zimbra interprets the ics file with recurring events differently than evolution? Any other suggestions would be very welcome.