If you don't have multiple procs, you don't need smp anyway.
I think I have SMP turned off. I added the line nosmp to the kernel line, but upon boot it freaked out and gave an error message to the affect of, "invalid reference to IRQ 0". So, I added noapic nolapic to the kernel line and it booted just fine. Since this is a single processor system, how can I be sure SMP is disabled?
Adding the "nosmp" to the kernel line had no affect. Zimbra still crashed. I can't be 100% positive, but it looks like the ldap service is what starts the spiral. Do the previous logs seem to indicate that at all?
I was poking around in the /opt/zimbra and found the log I have attached. I don't know if it will help or not.
I am seriously thinking about an OS rebuild/Zimbra re-install. I will leet you know how that fairs.
I have re-built the mail server from the ground up. Ubuntu 6.06.1, bind and Zimbra 4.5.10. Zimbra is still crashing. The hardware specs are a VM on ESX running 1 CPU, 2 GB RAM, Zimbra running from a 15 GB partition.
Here is an example of what I am seeing in syslog:
Dec 6 11:40:12 asok zimbramon: 15762:info: 2007-12-06 11:40:06, DISK: # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0xb7f163c1, pid=15798, tid=3047054256 # # Java VM: Java HotSpot(TM) Client VM (1.6.0_02-b05 mixed mode, sharing) # Problematic frame: # C 0xb7f163c1 # # An error report file with more information is saved as /tmp/hs_err_pid15798.log # # If you would like to submit a bug report, please visit: # HotSpot Virtual Machine Error Reporting Page #: dev: /dev/sda4, mp: /, tot: 2819, avail: 1737
Dec 6 12:02:41 asok slapd: daemon: shutdown requested and initiated.
The above slapd error is the beginning of the crash. What could be causing this server to crash. I have met all of the requirements for this to run. Does anyone have any ideas?
Try Zimbra 4.5.5
and before I get flamed, I know it's an old version
What kind of file system are you using, and what VM?
The Filesystem is ext3. I am running ESX 2.5.5 on a DL-380 G1 with 4 GB of RAM. The VM is a single drive of about 20+ GB. I broke the partitions down like this:
/boot - 100MB
/var - 2GB
/ - 3GB
/opt - 20GB+
I gave the VM 2GB of RAM to work with right before it crashes there is always very little physical memory left. For example, I have seen it as low as 25MB of RAM left. I started this VM out with 512MB of RAM and have increased it over the last week trying to see if that would help.
Why would back tracking to 4.5.5 make a difference? Just curious.
Well, the fault indicates a disk problem. This is likely because of how your VM is handling IO for the disk. That isn't to say that it's wrong, but Java things it's wrong. The OS doesn't really care as long as it works.
In 4.5.6, we switched to Java 1.6. We were at 1.5
If it works, you know that there is some sort of computability problem with the disk and Java. If not, then we'll try some more stuff.
The good news is that RC2 has Java 1.5.
The bad news is that 5.0 GA will have Java 1.6
Or you can just buy a Mac.