Why Tomcat won’t start (with error in dependencyCheck)

Under HP-UX (and apparently several other systems, including Windows), Cocoon won’t start up.  Cocoon is an XML-based system that implements the “separation of concerns” for web development and runs on top of Tomcat.

The Tomcat error logs (located in $CATALINA_BASE/logs/catalina.out) report the following:

SEVERE: Error in dependencyCheck
java.util.zip.ZipException: invalid entry size (expected 2472738816 but got 48 bytes)

Checking and rechecking the cocoon.war file reports no errors – and checking all of the *.jar files located in cocoon/WEB-INF/lib report no errors. There is has been much discussion about this specific error in various mail files, and someone even put it into the Cocoon FAQ on their wiki (without a satisfactory answer).

The only hint of a resolution was one message that suggested that the batik-all-1.5b2.jar file was corrupted. The Windows-based 7zip reported no errors on batik-all-1.5b2.jar (at 2080760 bytes), but extracting and repacking Batik (with 7zip on Windows XP Professional) fixed the problem. The repacked batik-all-1.5b2.jar was 2075222 bytes, and now it works.

Apparently this error has been around for quite some time (months at least); why it exists in HP-UX 11i v3 is beyond me.

Why df and du don’t report the same disk space used….

Sooner or later, you’re bound to come up against this mystery.  Once you understand it, it’s not that much of a mystery – but it does seem quite unusual until you understand it.

The utility df reports disk used and disk free from the disk’s internal information; that is, how many blocks on disk are marked as free, and how many are not.  The utility du, on the other hand, reports how much space the selected files take up on disk.

Consider:

• df reports blocks marked as used.
• du reports blocks used by files.

The discreprency comes in based on those two facts: there are blocks marked as used that are not used by files.

How can that be?  Well, the mystery shall be revealed: when a file is deleted, if another process has it open, that file is not marked as free (though it is no longer in the filesystem).  This file remains open by the other process, but is no longer discoverable in the filesystem directory structure – and its disk blocks remain in use.

Now you know.