I think some documentation of the problem,
and a practical description of how users can
deal with it, is the most important thing.
Old unix-isms, like
cp test/foo.jar production/foo.jar
jar cf production/foo.jar ...
some...unix..command > production/foo.jar
rsync -a test/ production/
need to be exposed as avoidable (!) sources of SIGBUS.
I only recently learned about the following option
to rsync, which I have started using religiously
to try to reduce SIGBUS for my own customers:
--delay-updates
This option puts the temporary file from each updated file into
a holding directory until the end of the transfer, at which time
all the files are renamed into place in rapid succession. This
attempts to make the updating of the files a little more atomic.
By default the files are placed into a directory named "~tmp~"
in each file's destination directory, but if you've specified
the --partial-dir option, that directory will be used instead.
See the comments in the --partial-dir section for a discussion
of how this ".~tmp~" dir will be excluded from the transfer, and
what you can do if you want rsync to cleanup old "~tmp~" dirs
that might be lying around. Conflicts with --inplace and
--append.
Feel free to turn this email into educational material that
might reduce the SIGBUSes real users will encounter.
Martin
On Thu, Feb 25, 2010 at 11:09, Xueming Shen <xueming.s...@sun.com> wrote:
>
> http://cr.openjdk.java.net/~sherman/6929479/webrev/
>
> This is a rfe to add a system property sun.zip.disableMmap to enable the end
> user to disable the mmap usage in
> Sun's java.util.zip.ZipFile implementaiton (for Solaris and Linux
> platforms).
>
> Application uses java.util.zip.ZipFile might experience SIGBUS vm crash if
> the application mistakely over-writes
> zip/jar files that are still being used, for example the application server
> repeatedly deploy the same jar file into the
> same location again and again while there is still code (running in the same
> vm) still accessing this particular zip/
> jar file (access the memory that mmapped the central directory of the zip
> file). While this is indeed an programming
> error in the offending application, there is situation that the end user
> really does not have the control of those
> applications and look for a workaround for the crash. With this property set
> to true (-Dsun.zip.disableMmap=true)
> the sun zipfile implementation reads in the central directory into the
> memory instead of using mmap.
>
> Thanks,
> Sherman
>
