See subject. With recent kernel versions, you have to mount
/proc/sys/fs/binfmt_misc before using it. Unfortunately, it is not
described in the kernel documentation, but on
http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html

I also wish to see the needed wrapper scripts for Java binaries as
examples in the binfmt-support package.

Gruss/Regards,
Eduard.

Er, update-binfmts does do this. Look in the load_binfmt_misc()
function.

I'm not sure whether to have these as examples in binfmt-support, as a
separate package, or as part of java-common. I've had a separate
javawrapper package ready to go for a long time, but was never quite
sure if that was the best way to have it in Debian.

#include <hallo.h>
Colin Watson wrote on Sat Feb 16, 2002 um 11:53:27AM:
does not work as expected: The Module is not loaded automaticaly, and
instead, I see the message from:

    unless (-d $procdir) {
	warning "binfmt_misc module seemed to be loaded, but no $procdir",
		"directory! Giving up.";
	return 0;
    }

If I load the module manually, it works. But then, I cannot stop the
binfmt support:

/etc/init.d/binfmt-support stop
Disabling additional executable binary formats: binfmt_misc: Device or resource busy
update-binfmts: warning: Couldn't unload the binfmt_misc module.
binfmt-support.

And I cannot remove the module manually. The binfmt proc directory is
umounted, I stopped all process which could have something in common
with binfmt_misc, but lsmod still shows that the module is busy. I am
running out of ideas and cannot reboot the machine now to make more
tests.

It would be nice. Many people have non-official j2re1.3 package
installed or even kaffee to run Java applications.

Gruss/Regards,
Eduard.

I'd like to see the output of:

  PERLDB_OPTS='NonStop=1 AutoTrace' perl -d /usr/sbin/update-binfmts --enable

There'll be quite a lot of it.

Hm. Sounds like a kernel bug to me, but it's worked on other people's
2.4.17 builds ...

I'll have a look. I want to get the bug-squashing party out of the way
first, though.

#include <hallo.h>
Eduard Bloch wrote on Sat Feb 16, 2002 um 01:38:59PM:

So, I see the problem. With the current kernel version, the procfs
directory does exist even if the module has not been loaded yet.
Changing line 229 helps:

   if ($style eq 'procfs' and not -e "$procdir/register") {

Gruss/Regards,
Eduard.

But then you can't have seen the message above, which you said you saw.
I'm confused.

Can you send me the output I asked for?

Thanks,

#include <hallo.h>
Colin Watson wrote on Sat Feb 16, 2002 um 01:37:38PM:

As you wish, both logs, one with normal version, one with the changed
line. Compressed both.

Weird, weird. I am running 2.4.18rc1, and another guy could reproduce
this with an uknown kernel.

Gruss/Regards,
Eduard.

Ah, right, it was actually this warning you saw:

    if (-f $register) {
        return 1;
    } else {
        warning "binfmt_misc initialized, but $register missing! Giving up.";
        return 0;
    }

Thanks. I've now got 2.4.18 at work, so I'll test out a fix and probably
upload tomorrow. Sorry for the delay.

Turns out the 2.4.17 kernel my friend tried it out on beforehand had
binfmt_misc built in, so it used a different logic path.

Hi

I noticed this very old bug and wondered if it is still relevant.
Currently there is a jarwrapper package that uses binfmt-support to
allow jar-files to be executed.

~Niels

Hi

I noticed this very old bug and wondered if it is still relevant.
Currently there is a jarwrapper package that uses binfmt-support to
allow jar-files to be executed.

~Niels

Almost.  It's probably more use to most people than my javawrapper
implementation is, I agree.

When I wrote javawrapper, it was in the early days of Java and it was
still common enough to just build a pile of .class files rather than a
.jar file.  I wrote javawrapper because I was fed up with concocting the
correct syntax to get the Java interpreter to start with a given .class
file.  This still seems as though it could be useful in some situations.

CCing the javatools maintainers; would it be possible to merge some of
the functionality of
http://www.chiark.greenend.org.uk/~cjwatson/code/javawrapper/javawrapper-1.0.tar.gz
into jarwrapper?

Thanks,

Almost.  It's probably more use to most people than my javawrapper
implementation is, I agree.

When I wrote javawrapper, it was in the early days of Java and it was
still common enough to just build a pile of .class files rather than a
.jar file.  I wrote javawrapper because I was fed up with concocting the
correct syntax to get the Java interpreter to start with a given .class
file.  This still seems as though it could be useful in some situations.

CCing the javatools maintainers; would it be possible to merge some of
the functionality of
http://www.chiark.greenend.org.uk/~cjwatson/code/javawrapper/javawrapper-1.0.tar.gz
into jarwrapper?

Thanks,

=2E
r-1.0.tar.gz

Hi again

Sorry for the late reply.

It is possible add this feature to jarwrapper, but I am not sure that it
make sense these days. Personally I hardly ever run a class directly;
either my IDE start the program for me or I bundle it into a jar first.
  On a related note, the Debian Java Policy requires that all class
files are bundled into jar files, so it will not add any value for Java
packaging.

I do not mind supporting this if our users actually want this feature.

~Niels

=2E
r-1.0.tar.gz

Hi again

Sorry for the late reply.

It is possible add this feature to jarwrapper, but I am not sure that it
make sense these days. Personally I hardly ever run a class directly;
either my IDE start the program for me or I bundle it into a jar first.
  On a related note, the Debian Java Policy requires that all class
files are bundled into jar files, so it will not add any value for Java
packaging.

I do not mind supporting this if our users actually want this feature.

~Niels

Actually, does either javawrapper or even jarwrapper make sense these days now that openjdk already register jar files in binfmts?

Granted, jarwrapper does at least one thing better than openjdk: it provides a proper jar detector,  while openjdk relies only on magic numbers. Which matches not only .jar files but *any* zip file, including its subclasses like MS Office's docx / xlsx / etc.

So, I wonder if jar/javawrapper could be merged into openjdk? If only to make its binfmts entry a little more robust with a detector?

I detailed this issue in bug #706200, and I even describe (and suggest) jarwrapper's approach., so maybe joining efforts is a good idea?

Regards,
ML

Some more info these days:

https://lists.debian.org/debian-java/2014/10/msg00087.html

[...]

Could someone please describe what is going with binfmts and jar files ?

This is a followup from #764630. On my brand new jessie (amd64) system
I can see:

$ cat /proc/sys/fs/binfmt_misc/jar
enabled
interpreter /usr/bin/jexec
flags:
offset 0
magic 504b0304

while:

$ cat /proc/sys/fs/binfmt_misc/jarwrapper
enabled
interpreter /usr/lib/binfmt-support/run-detectors
flags:
offset 0
magic 504b0304

Why do we have two binfmts handlers for the same magic ?

Thanks for clarification
[...]