Activity for Yet Another Java Service Wrapper
-
K S Kumar posted a comment on discussion Open Discussion
@rzorzorzo The workaroud is working and able to bring up the application as a service. Thank you
-
rzo modified a comment on ticket #62
Now i found out that when i set wrapper.console.pipestreams = false then i can start / stop the app pipestreams is only intended for testing and should not be used in production. however the app should run as service and console with or without it. if it does not run as a service with pipestreams set, then this may indicate that there is an issue with user rights. Only one Exception Message in then wrapper.log occurs. Have you an idea why? this may be the same issue as above. the wrapped app is opening...
-
Now i found out that when i set wrapper.console.pipestreams = false then i can start / stop the app pipestreams is only intended for testing and should not be used in production. however the app should run as service and console with or without it. if it does not run as a service with pipestreams set, then this may indicate that there is an issue with user rights. Only one Exception Message in then wrapper.log occurs. Have you an idea why? this may be the same issue as above. the wrapped app is opening...
-
Now i found out that when i set wrapper.console.pipestreams = false then i can start / stop the app pipestreams is only intended for testing and should not be used in production. however the app should run as service and console with or without it. if it does not run as a service with pipestreams set, then this may indicate that there is an issue with user rights. Only one Exception Message in then wrapper.log occurs. Have you an idea why? this may be the same issue as above. the wrapped app is opening...
-
the netty vulnerabilities concern the http implementation, the jar of which is not included with yajsw. so this is not critical. an update will follow in the next release. updating netty, or groovy is not that simple, as some classes are shadowed in yajsw: https://sourceforge.net/p/yajsw/yajsw/ci/master/tree/src/yajsw/src/main/java/io/netty/ when updating jars one has to update the manifest file: https://sourceforge.net/p/yajsw/yajsw/ci/master/tree/build/MANIFEST.MF -- Ron
-
Ravi Raj created ticket #34
CC 2.8.0 Vulnerabilities
-
Sure @rzorzorzo. I will try that workaround and let you know the result. Again netty*4-1.104 has vulnerabilities. Shall i replace the jars to latest ? or it need testing altogether?
-
Markus Müller posted a comment on ticket #62
Hello Ron, running our app as console works properly. As you can see the wrapper.console.pipestreams = true was already set. Now i found out that when i set wrapper.console.pipestreams = false then i can start / stop the app and it seems to work. Only one Exception Message in then wrapper.log occurs. Have you an idea why? Markus
-
thanks for the feedback. there seems to be an issue with groovy 4 and java 22. weird, i thought i tested the latest version with java 22. in your case: according to your config you do not need groovy. simple interpolation is sufficient. so as a workaround go to lib/extended and just rename the folder groovy to for example groovyx. this will result in an error that groovy is missing, but the application should run as expected. let me know if this helps. -- Ron
-
@rzorzorzo Thank you for responding and here is the configuration and error log. Please let us know any workaround. And also now netty*4-1.104 also having vulnerabilities. Can we replace those jars with latest ?? WARNING - Do not modify any of the properties when an application using this configuration file has been installed as a service or daemon. Please uninstall the service before modifying this file. The service must then be reinstalled. ********** working directory ********** wrapper.working.dir=${wrapper_home}...
-
hello, pls upload your configuration and the resulting log file. remember to remove passwords or other private data from the files before uploading. -- Ron
-
@rzorzorzo I am facing issue with java 22 & yajsw 13.12, groovy scripts are giving class version errors; And the applciation is working perfectly in console mode. The below error is thrown only in service/daemon mode. Exception stacktrace: Caused by: BUG! exception in phase 'semantic analysis' in source unit 'Script1.groovy' Unsupported class file major version 66 at org.codehaus.groovy.control.CompilationUnit$ISourceUnitOperation.doPhaseOperation(CompilationUnit.java:901) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:692)...
-
hello, pls check if your app is java 21 compatible by running it with java 21 without the wrapper. before running as service try running it as console, by calling bat/runConsole.bat the logging suggests that there is an issue launching the java sub process. to see some more logging as to why your app does not launch pls set in the conf file the following: wrapper.console.pipestreams = true then run as console and check the console output. -- Ron
-
wrapper don't Work with Java 21
-
jackson-core-2.11.3 - vulnerability
-
Netty 4.1.104 Final - vulnerability
-
Glazed Lists binary Vulnerabilities
-
https://github.com/glazedlists/glazedlists/issues/709
-
commons-net3.2 - vulnerability
-
as the logging states: you have enterd the PID of the cmd process not the one of the java process. -- Ron
-
commons-net3.2 - vulnerability
-
muthu5 created ticket #61
In windows wrapper.conf is empty while executing genConfig.bat <pid>
-
jackson-core-2.11.3 - vulnerability
-
Netty 4.1.104 Final - vulnerability
-
Glazed Lists binary Vulnerabilities
-
Bug in setenv (wrongjava_exe)
-
thanks correct file can be found in git.
-
Lutz Bergmann created ticket #207
Bug in setenv (wrongjava_exe)
-
Antonio posted a comment on discussion Help
Hi Ron, Thanks for the help. It looks like I had some legacy JVM config parameter that was deprecated in newer java versions and wasn't compatible with java 17 and it was stopping JVM from starting which in the end caused all the other previous issues. It worked previously on java 8 and that's why I didn't think it was a problem. I found out it was causing issues by running the runConsole.bat which showed one line that hinted me the error. The parameter was: wrapper.java.additional.3=-XX:PermSize=384m...
-
hello, the exception that is thrown is not the cause of the issue. the main issue, is that the sub process cannot run. this is generally due to issues such as user rights, unmapped network drives, unsupported java class version, ... the exception only indicates that the wrapper process cannot "connect" to the output of the child process. before running as service pls run using yajsw/bat/runconsole.bat, while pipestreams and the java full path are set as described above. if this runs without issues,...
-
Hi Ron, Thanks for answering. Changing wrapper.java.command to full path didnt seem to make any difference. Setting wrapper.console.pipestreams=true made the error message to change a bit. Now it is instead of a previous error saying "Exception in org.rzo.yajsw.log.MyLogger: java.io.IOException: Stream Closed" Attaching log with new error. Antonio
-
thanks for the feedback
-
hello, pls set the following configuration: wrapper.console.pipestreams = true this will give some more information when the startup of the process fails. remember to remove it when the issue is solved. pls also try setting wrapper.java.command= full path to java exe make sure that java.exe is executable for all users remember to uninstall the service before doing any changes to the conf. -- Ron
-
Juan Marques posted a comment on ticket #60
Hi Ron, I've updated the installDaemonNoPriv.sh script for installing the YAJSW daemon with the following changes: Source Command Quotation Fix: Changed source "$PRGDIR"/setenv.sh to source "$PRGDIR/setenv.sh". This fixes potential issues with the quotation marks, ensuring the correct path is sourced. Configuration File Argument Check: Added a check to ensure a configuration file is provided as an argument when running the script. If no argument is given, the script will now output a message and...
-
Picture of service installation and wrapper.conf
-
Picture of service installation
-
Picture of service installation
-
Hi, I am currently migrating applications from java 8 to java 17. We previously used version 11.11 of YAJSW but not it is not working on java 17 so I am updating it. I have read that minimum release version supporting java 9+ is 13.xx so I tried 13.03, 13.09 and 13.12 but I am getting the same error nonetheless. I had to change some wrapper.conf properties related how they were configured previously but somehow it worked while now it is not working anymore. Still after changing some of those properties...
-
hello, your wrapper.conf is for an older version of yajsw. pls compare it with the wrapper.conf.default file in the current release. (see the section wrapper posix systemd props). however the file should also work with the current release. as stated i have the feeling that your installation is not ok. you are using the wrong conf file or an empty one. i propose that you redo everything from scratch as described in the documentation (quick start). -- Ron
-
Hello Ron! I'm upgrading from 13.3 to the latest version which support java 21. I have been using the same conf file for years now.. Please take a look on the full conf file. Kind regards, Juan Marques
-
hello, it seems as if yajsw is not using the config file shown here. pls provide more details: - are you upgrading from an older yajsw installation ? - how did you install ? - how did you create the conf file ? - maybe there are some non printable characters in the conf file. maybe not UTF-8 ? the message "no name for daemon" indicates that wrapper.ntservice.name is not set. -- Ron
-
WARNING: no name for daemon -> abort
-
yes, to all your questions. you may also try to set wrapper.java.command to the full path of the java exe and wrapper.working.dir to the full path of the work dir. remeber to deinstall the service before making any configuration changes. -- Ron
-
Vishal Kumar Gupta posted a comment on ticket #206
Hi @rzorzorzo Thank you so much for your prompt response and help. I assume, that this only happens when the computer boots -- Yes I am adding more details Like we are getting event ID 7000 and 7009 in this issue case. 7009 - A Timeout was Reached (30000 milliseconds) while waiting for the IPS service to connect. 7000 - The service did not respond to the start or control request in a timely fashion. I attached herewith the windows event screen shot image for the same when this issue happened. We...
-
hello, i assume, that this only happens when the computer boots. that nothing is written to the yajsw log file. that everything is fine if the server is already up. in most cases this indicates that the service is started before the boot is complete. in your case you are using an env var as working dir. this env var may not be available if the service is started too early. try setting: wrapper.ntservice.starttype=DELAYED_AUTO_START or the following: wrapper.ntservice.failure_actions.xxx or: wrapper.ntservice.dependency.1=Netman...
-
I just added the Wrapper conf file again as in ticket it is not showing correctly.
-
Service failed to Start in Windows 10 System Restart
-
teapot418 posted a comment on ticket #201
yes, Issue is solved, thank you.
-
release 13.12
-
release 13.12
-
yajsw-stable-13.12 released
-
Yet Another Java Service Wrapper released /yajsw/yajsw-stable-13.12/yajsw-stable-13.12.zip
-
-
thanks for message. release 13.12
-
YAJSW
-
Issue in bundling the product to my server
-
Issue in Staring the service.
-
Service Status
-
set wrapper_home
-
CVE-2023-34462 reported against netty
-
Version 13.08 logs that it is version 13.07
-
Invalid documentation references to jna.tmpdir
-
release 13.12 pls report if this issue is resolved or not.
-
thanks for reporting. release 13.12 should be available in apprx a week. -- Ron
-
you are using an old release of yajsw. pls update to the newest release 13.11 and try again. you may also try setting the configuration: wrapper.java.command = path to java exe -- Ron
-
you are using an old release of yajsw. pls update to the newest release 13.11 and try again. you may also try setting the configuration: wrapper.java.command = <path to="" java="" exe=""></path> -- Ron
-
lkming created ticket #59
Error
-
Shivani Pacharne posted a comment on discussion Help
We are using YAJSW 13.07 in our project and security team has identified 2 CVEs (CVE-2024-29131 & CVE-2024-29133) for commons-configuration2-2.8.0.jar present inside yajsw-stable-13.07\lib\core\commons. Also, I have checked for latest YAJSW version 13.11, the commons library is in its old version (commons-configuration2-2.8.0.jar). Could you please let me know if the CVEs are exploiting YAJSW 13.07? If yes, when can we expect its fix.
-
Duncan posted a comment on discussion Open Discussion
Just in case this ever affects anyone else migrating from the Tanuki Software JSW and using old conf files as the basis. There's a JSW conf property called wrapper.java.additional.auto_bits which breaks YAJSW; because it sees that as an additional option to pass to Java; so adds whatever the propety is set to directly to the Java command line, which makes it fail! I have no idea why the old software I'm trying to update used the option anyway, since it doesn't apply to Windows, which is the only...
-
The wrapper.java.app.relativize_classpath option does not work as stated; due to the fact that in the code, it's actually looking for "wrapper.java.app.relativize_classapth" (line 502 in WrappedJavaProcess.java) I have worked around this and any potential future fix by setting both options in my conf: wrapper.java.app.relativize_classpath=true wrapper.java.app.relativize_classapth=true
-
:(( sorry. i will have to check this. -- Ron
-
Hi Ron, Thanks for the information. Thanks, Muthu.
-
hello, I have tried this in new release 13.11, but nothing changed, problem still continues Regards Monika
-
ps: you may also try systemctl start <service> instead of startDaemon.sh</service>
-
hi, if an app runs as console but not as daemon this is often due to user rights, or working dir. check the log file to see what the problem is. evntl set wrapper.debug = true wrapper.console.pipestreams = true to see more logging. -- Ron
-
Hi Ron, Thanks for the information. In yajsw, runConsole.sh starts the server perfectly. While executing ./startDaemon.sh it fails to start the server. In what cases runConsole.sh works fine and ./startDaemon.sh fails to start. Using : yajsw-stable-13.11, OS : Linux Thanks, Muthu.
-
Hi Ron, Thanks for the information. In yajsw, runConsole.sh starts the server perfectly. While executing ./startDaemon.sh it fails to start the server. In what cases runConsole.sh works fine and ./startDaemon.sh fails to start. Thanks, Muthu.
-
new release: yajsw-stable-13.11
-
-
-
release 13.11, do not check posix exit signal on windows
-
release 13.11 missing changes
-
release 13.11
-
thanks for reporting. will be resolved with release 13.11
-
starttype should have no effect on the timeout. pls add wrapper.debug = true and wrapper.console.pipestreams=true and post the log file and the console output of the console where you start the daemon -- Ron
-
Netty Project is affected CVE-2023-44487 - famous HTTP/2 reset/dos issue
-
release 13.11
-
Apache Jackrabbit 2.21.4 Java object deserialization issue
-
release 13.11
-
jdk 21 has not yet been tested yet. however changes in jdk 20 -> 21 should not affect yajsw. it will be tested for the next release. -- Ron
-
pls provide more information: log file, error messages, ...
-
yajsw requires absolute path for java and wrapper. on linux you could try setting WorkingDirectory (see https://www.baeldung.com/linux/systemd-service-working-directory) and you could the set the relative path for wrapper. however you will have to edit the service file after each invocation of daemonInstall.sh -- Ron
-
HI Team This is the blocking isssue, for us. Could you please inform, how to mention the relative path for wrapper.working.dir Thanks, Muthu
-
set wrapper_home
-
Service Status