Archive for October 24th, 2007

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.


Add comment 24 October 2007

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.


Add comment 24 October 2007


David Douthitt

David is an experienced UNIX and Linux system administrator, a former Linux distribution maintainer, and author of two books ("Advanced Topics in System Administration" and "GNU Screen: A Comprehensive Manual").

View David Douthitt's profile on LinkedIn

Top Posts

Calendar

October 2007
M T W T F S S
« Sep   Nov »
1234567
891011121314
15161718192021
22232425262728
293031  

Recent Posts

Recent Comments

ddouthitt on Core Linux - packages
GRUBówka « Bl… on Installing GRUB on FreeBS…
monsun on Installing GRUB on FreeBS…
hictio on Core Linux - packages
locky on Installing GRUB on FreeBS…

Category Cloud

BSD Career Debian Debugging Fedora FreeBSD HPUX Learning Linux MacOS X Mind Hacks Mobile Computing NetBSD Networking OpenBSD OpenSolaris Open Source OpenVMS Personal Notes Portable Presentations Programming Red Hat Scripting Security Solaris Tips Ubuntu UNIX Wheel Group

Archives

Links