I've added clj-ssh as a dependency to a Leiningen project, and I can (use 'clj-ssh.ssh) but calling (ssh-agent {}) gives the error
UnsatisfiedLinkError Unable to load library 'c': The specified module cannot be found.
at com.sun.jna.NativeLibrary.loadNativeLibrary
...
at org.jcraft.jsch.agentproxy.usocket.JNAUSocketFactory$CLibrary.(clinit)
...
Anyone know why this is? I'm thinking it could be to do with Windows not coming with a C standard library, in which case could installing e.g. cygwin help?
Try installing cygwin and add something like:
-Djava.library.path=...path to lib dir ...
if it doesn't find the library on it's own.
I'm the author of jsch-agent-proxy, which has been used in clj-ssh.
I think it will not work for cygwin's ssh-agent, because JNA does not provide
the native library for it. How about trying Putty's Pageant? If you need to use cygwin's ssh-agent and "nc" command exits on your cygwin environment, how about using NCUSocketFactory? I'm not so familiar with clj-ssh, but it will be possible to use NCUSocketFactroy instead of JNAUSocketFactory, according to agent.clj.
UPDATE:
I have confirmed that I can successfully run clj-ssh with
ssh-agent on my Cygwin environment by applying the following commit,
GitHub clj-ssh commit:f1109e2c0dfa25c9db563b2f64d2b7dcb4653adf
Ok, after some digging in the source it seems that clj-ssh attempts to use the system ssh-agent by default (which seems like strange behaviour if it isn't windows compatible). This makes clj-ssh.cli unusable but clj-ssh.ssh is fine with the fix
(ssh-agent {:use-system-ssh-agent false})
If you do want to use a system ssh-agent, the readme for clj-ssh and ymnk below mention PuTTY's pageant, I couldn't find any info on setting this up but it should be doable with cygwin.
I've seen this if the SSH_AUTH_SOCK environment variable is set. Clearing this environment variable before starting the jvm might solve the issue.
When SSH_AUTH_SOCK is not set, clj-ssh should automatically use pageant if it is running.
Looks like the best solution would be to support NCUSocketFactory as per ymnk's commit, and add documentation about cygwin's ssh-agent. Happy to take a pull request for that.
Related
I had SunOs 5.10 unix server , where i had written a script to execute a java file which is as below
#!/bin/ksh -x
export JAVA_HOME=openjdk1.8.0_331/bin
$JAVA_HOME/java com.myclass.MyClient
in this script there is alot of code which includes log file, and other binaries class path added before exporting JAVA HOME. But when i am executing i am getting the below error
openjdk1.8.0_331/bin/java : Cannot execute
i had changes lot of java versions but getting the same error
Your JAVA_HOME is not an absolute path. This is broken; many tools will just fail when you do this. Just make it an absolute path. It may or may not explain your error, but it's a ticking timebomb.
JAVA_HOME cannot be bin; its the level above bin.
It looks like you're using JAVA_HOME as an ersatz script variable to make your script work, but this is wrong: JAVA_HOME is used by all sorts of tools and has a very specific meaning, and it's not whatever you think it is.
There are 2 obvious explanations for your error:
Some tool sees JAVA_HOME, attempts to run java based on this, and fails, because your JAVA_HOME is broken. There's a ton of infra that is 'custom' per OS, and it may well be that the SunOS setup didn't fail if you set JAVA_HOME to broken values, but it does fail here. The fix is to not have broken JAVA_HOME, not to start looking for a setup on your new OS that can deal with broken JAVA_HOME settings. In other words, your script was always broken, it just so happens that your specific set up on that specific server on that specific version of sun OS so happened to be capable of dealing with the mess.
A much simpler explanation is also possible: That executable does not run on your OS+Architecture combination. trivially testable: Do NOT set JAVA_HOME at all and just try to run that java executable by e.g. cd ing to the path and running ./java -version. See what happens. If that also gives you cannot execute, voila - the script isn't the problem (though it still has a broken JAVA_HOME you should be fixing), you need to install a JVM that works on your OS+Architecture.
I have tried loading the latest versions of GraalVm from the site onto OS/X from : graalvm-ce-java11-darwin-amd64-20.2.0.tar.gz
I tar this bundle, following the instructions and sudo mv the directory to /Libaray/Java/JavaVirtualMachines and setup the .bash_profile per the instructions. If I run the java_home -V command I see the VM there.
When I try to execute any of the command line utilizes from the VM (java, javac, jar, etc.) I get a fault by OS/X saying the application is from an untrusted developer. I then I have to to control panel/security and settings/general and manually select each an every binary and each and every native library one at a time and tell OS/X to add them as an exception to allow them to be run.
Am I missing something or is this expected behavior? Is there a better way to install the graalVM on OS/X?
This is an old issue but maybe it helps:
https://github.com/oracle/graal/issues/1724
I wonder why this has not been fixed yet.
I am trying to use psutil library in MacOS via Jython but when I make a call to psutil.cpu_times function, I get the following error.
except AccessDenied as err:
In psutil documentation the reason is explained as following.
Note (OSX) psutil.AccessDenied is always raised unless running as root
(lsof does the same).
Is there a way to overcome this problem? I will run the program in Linux enviroment after development so a temporary solution will be fine.
Thanks.
For those who land on this page looking for an answer to the same question. I couldn't find a solution to this problem and returned back to extracting system status from /sys.
I am trying to create service for Windows.
I have .bat script that launches jetty with solr:
cd ../jetty
java -Djetty.home="C:/Webs/lrt-archyvas/jetty" -Djava.ext.dirs="C:/Webs/lrt-archyvas/parts/jetty-download/lib;C:/Webs/lrt-archyvas/parts/jetty-download/lib/jsp" -jar C:/Webs/lrt-archyvas/parts/jetty-download/start.jar C:/Webs/lrt-archyvas/jetty/etc/jetty.xml C:/Webs/lrt-archyvas/jetty/etc/jetty-deploy.xml C:/Webs/lrt-archyvas/jetty/etc/jetty-webapps.xml OPTIONS=Server,jmx,resources,websocket,ext,plus,annotations
I want to create service and in that case I want to use this http://drupal.org/node/1359598 tutorial.
Problem is that I can't use cd and go into jetty directory. I have to set it in parameters but I am unable to.
When I run this script from other directory I get the following:
2012-03-02 13:04:51.493:INFO::jetty-7.3.1.v20110307
2012-03-02 13:04:51.511:INFO::Deployment monitor C:\Webs\lrt-archyvas\bin\webapp
s at interval 1
2012-03-02 13:04:51.538:INFO::Started SelectChannelConnector#0.0.0.0:8080
It uses "C:\Webs\lrt-archyvas\bin\" (cwd) as jetty.home to load webapps. And I set it to C:/Webs/lrt-archyvas/jetty.
How can I override this?
You can set jetty.home on the java commandline with -Djetty.home="C:\foo"
(you also ought to use windows paths for that to work I suspect, hence the backslashes)
the jetty start mechanism should pick this setting up and operate from there
I should add that since this is jetty 7 apparently being used there ought to be a start.ini file somewhere in there that you should be able to specify the options and xml files on. You can use the --dry-run option to have the actual option string that is being used.
If you experiment with --dry-run you should be able to iron out the precise string to drop into that service window for things to work. That ought to take some of the tedious process out of determining the correct string.
cheers
I fear not being very helpful ...
Could you give us more details ?
What kind of software are you trying to use to set your application as a Windows service.
Don't know if you can afford to use this product but it's a very good one :
tutorial article
download page
Have you edited the start.config Jetty file ? I guess it may be confused by a wrong location of the jar file (jetty home is computed like this in Jetty)....
HTH
Jerome
You can try using procrun from Apache Commons Daemon project. Following post has lot of details.
Running Jetty 7 as Windows Service
You can be easily run as a Windows service Solr can be used to exewrap.
Solr Windows Service all-in-one packages are also distributed.
http://exewrap.sourceforge.jp/solr/
I am getting a error message like this:
The library libraryname.dll could not be loaded by Windows. Make
sure that the library is in you Path environment variable. Exception
in thread "main" java.lang.UnsatifiedLinkError: no libraryname in
java.library.path.
This error is from me trying to run a jar file on Windows XP via cmd. I am wondering, where exactly is java.library.path? I've already added C:\Program Files\Java\jdk1.6.0_26 to my PATH but it still gives me the error. How would you go about debugging this?
Thanks.
You can simply pass java.library.path as a system property as shown below:
java -Djava.library.path=<path_to_dll> <main_class>
First you need to find out where the libraryname.dll is and add it above in "path_to_dll".
The error is basically saying it cannot find your native libraries. Java tries to locate your library by looking into java.library.path property
It's an System environment that you need so Java can find your native libraries when you run your application. Several ways to do it:
Use java -Djava.library.path=[path to your library] when running your program
From the code you could also do.
System.setProperty( "java.library.path", "/path/to/libs" );
Set it up from your IDE. An example for Eclipse can be found in this SO question How to set java.library.path from eclipse
EDIT: A good comment below pointed out that #2 will not working 100% because you might not set this prior to calling getProperty(). Missed that point and thanks for pointing that out.