环境变量干扰jar
我有一个 jar 文件,它可以在许多机器上运行。然而,我们只是要求一个新的 unix 用户来安装它,但它的行为并不相同......不知道它是否可能与某些环境相关。变种
基本思想是:
WorkingUser@box$ java -jar install.jar -h
[output help instructions]
但是
NewUser@box$ java -jar install.jar -h
The java class is not found: pkg1.pkg2.pkg3.Loader
在任何人询问之前,不需要类路径,是的,jar 的 cksum 是可以的。事实上:
$ jar tf install.jar
META-INF/
META-INF/MANIFEST.MF
pkg1/
pkg1/pkg2/
pkg1/pkg2/pkg3/
pkg1/pkg2/pkg3/script/
pkg1/pkg2/pkg3/Loader.class
pkg1/pkg2/pkg3/LoaderHelper.class
package.jar
您可以认为 MANIFEST.MF 没问题,因为它适用于其他用户。
我尝试使用 -cp install.jar
执行但没有成功。此外,工作和非工作用户的 $CLASSPATH
仅包含“.
”。
有什么线索吗?
谢谢,
f。
I have a jar file, which works in many machines. However we just asked for a new unix user to install it, and it is not behaving the same... wonder if it could be anything related to some env. var.
the basic idea is:
WorkingUser@box$ java -jar install.jar -h
[output help instructions]
but then
NewUser@box$ java -jar install.jar -h
The java class is not found: pkg1.pkg2.pkg3.Loader
Before anyone asks, there is not classpath needed and yes, the cksum for the jar is ok. in fact:
$ jar tf install.jar
META-INF/
META-INF/MANIFEST.MF
pkg1/
pkg1/pkg2/
pkg1/pkg2/pkg3/
pkg1/pkg2/pkg3/script/
pkg1/pkg2/pkg3/Loader.class
pkg1/pkg2/pkg3/LoaderHelper.class
package.jar
And you can figure that the MANIFEST.MF
is fine, since it works in other users.
I have tried executing with -cp install.jar
with no success. Also the $CLASSPATH
for working and not working users contains only ".
".
any clues?
thanks,
f.
我正在复制 serverfault 中 davey 的答案,以将其关闭。接下来。
尝试将文件复制到 /tmp 或 /var/tmp 并从那里运行安装。它会进一步/成功吗?
[编辑]
这非常接近实际问题。我最终做了一个类似的测试,该测试有效,并且经过一些测试后我发现挂载点权限是错误的,即挂载用户fs的文件夹属于root em> 并有权访问
774
(无法执行其他)。我总是很着迷地发现低级别的错误权限如何对上层造成最不利的影响。我曾经(而且我仍然不太确定)安装点的权限影响了安装的文件系统...
无论如何,我们给了它 exec 权限,瞧,java发现它是类。整个安装还有更多问题,但这些问题可能会涉及其他问题:)
谢谢大家。
I'm copping the answer from davey in serverfault to have this closed. follows.
Try copying the file to /tmp or /var/tmp and running the install from there. Does it get further/succeed?
[EDIT]
This was pretty close to the actual problem. I ended up doing a similar test which worked and which with some testing lead me to find that the mount point permissions were wrong, i.e. the folder where the user's fs is mounted belongs to root and had access
774
(no exec to others).I find always fascinating how wrong permissions in a low level cause the most adverse effects in the upper layers. I had (and I'm still not quite sure of it) that the permissions of the mount point had affect the mounted fs...
Anyways, we gave it the exec permission and voilá, java finds it's classes. There are more problems with this whole installation, but these might go to other questions :)
Thanks all.