Activity for rzo
-
rzo posted a comment on discussion Help
yes, app9 was removed in release 3.11 the handling of java modularization changed and did no longer require jdk9+ specific code. see: https://sourceforge.net/p/yajsw/yajsw/commit_browser -- Ron
-
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
-
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
-
hello, pls upload your configuration and the resulting log file. remember to remove passwords or other private data from the files before uploading. -- Ron
-
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
-
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
-
Bug in setenv (wrongjava_exe)
-
thanks correct file can be found in git.
-
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,...
-
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
-
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, 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
-
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
-
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...
-
release 13.12
-
release 13.12
-
yajsw-stable-13.12 released
-
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
-
:(( sorry. i will have to check this. -- Ron
-
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
-
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
-
pls try the following: remove: wrapper.java.app.module = application add: wrapper.java.additional.1=--add-modules wrapper.java.additional.2=application wrapper.java.additional.3=-p wrapper.java.additional.4=./application/target/classes;./plugin-api/target/classes;./plugin-impl/target/classes it works for me with the example. -- Ron
-
i now see: the 30 secs are hard coded in the startDaemon command: when starting a service we need to start a demonized sub-process. this means we have no direct communication with the process. the command then checks in 1 sec cycle for 30 secs if the service is up. since in your case the service stops immediately the check always returns false. so after 30 seconds the command prints that the service did not start. when starting a service manually, the standard use case is that the service starts...
-
in the case that the tray is not working corretly: pls provide the output of the tray console and of the wrapper log file. thanks. -- Ron
-
thanks a ton for providing the reproducer. i am currently very busy with other work. i will get to it asap. -- Ron
-
as stated: update the log settings as described above set the debug property start the service post the log file which contains the time stamps. without the time stamps it is difficult to see what is going on. -- Ron
-
concerning 1: this is probably a timing issue. startService initiates the start of the service and then for a timeout (30 s hard coded) checks if the service is up. on some servers/applications this may take longer. So pls check using the windows ui or process explorer if the service is started. i assume that running startService for a second time finds out that the service is already up and reports it. concerning 2: pls refer to the docs. -q will print the status of the service. -- Ron
-
yajsw comes with a system tray icon. note that this will only not work on linux witout a desktop. check the documentation for details. -- Ron
-
it is not recommended to mix yajsw and the wrapped application. it is best to keep them in separate folders as described in the documentation. mixing them may result in classpath issues, difficulties when upgrading yajsw or your application. to reduce the size of your delivery you may remove some files/folders from the yajsw distribution. for example the src folder, some folders in lib/extended (see readme files), ... before running your application as service first make sure it runs using runConsole.bat....
-
thanks for the feedback. looking at the config: pls change as follows: #******************************************************************** # Wrapper Logging Properties #******************************************************************** # Format of output for the console. (See docs for formats) # wrapper.console.format=PM # Log Level for console output. (See docs for log levels) wrapper.console.loglevel=INFO # Log file to use for wrapper output logging. wrapper.logfile=${wrapper_home}/log/wrapper.log...
-
pls post the log file and config file pls remember to remove any private data such as passwords. what do you meand by "time that the wrapper takes to fail" ? -- Ron
-
release 13.11
-
Hello, thanks for reporting the issue. Could you pls provide some more details on how your application is built, or better a reproducer. In the mean time I will try to reproduce the issue. I assume that this may be a classloader issue. -- ron
-
sometime next week. -- Ron
-
thanks for pointing this out. will check this for release 13.11 -- Ron
-
thanks for reporting: release 13.11 gradle 8
-
Apache Jackrabbit - 2.21.4 vulnerability CVE-2023-37895
-
release 13.11
-
thanks for reporting. this is a bug release: 13.11
-
yajsw is not available on maven. so no maven link. all is checked in to the git repository on sourceforge,. there, you can find the history of each folder/file. the latest release of ahessian.jar was with release yajsw 12.09: https://sourceforge.net/p/yajsw/yajsw/ci/337b43cb450455f1abce1f99ee16e41b42ce5cfc/log/?path=/lib/core/yajsw click on "tree" to view the file within a release. -- Ron
-
hello, source for ahessian is provided here: https://sourceforge.net/p/yajsw/yajsw/ci/master/tree/src/ahessian/src/main/java/ it is dependent on: https://sourceforge.net/p/yajsw/yajsw/ci/master/tree/src/hessian/src/main/java/com/caucho/hessian4/ and on netty-xxx-4.1.86.Final see: https://sourceforge.net/p/yajsw/yajsw/ci/master/tree/lib/core/netty/ the package com.caucho.hessian4 has been taken from the subversion repository of: http://hessian.caucho.com/ and for some historical reasons the package...
-
difficult to say, do you have the issue only when it is running as service ? or also when running using runConsole ? OS ? pls try the following: set the config: wrapper.debug =true wrapper.console.pipestreams = true maybe we would get some more logging. try removing the prometheus agent to make sure this is not the cause. is your application based on known framework such as wildfly or spring ? this would maybe help me reproduce your issue. -- Ron
-
your config does not seem to be ok. Q: can you run your application in a console without a wrapper ? if yes, it would be easier for you to proceed as described in the quick start of the yajsw documentation. your configuration is missing the working dir of your application, the classpath to your application. the classpath to the wrapper jars is not needed. it is also missing the jar or main class to invoke. the log file name format is not OK. pls check the docs. concerning your questions: JVM checks...
-
hello, is the log file from running your app as service ? or with runConsole.bat ? pls try the following: set the following properties in the conf file: wrapper.debug = true wrapper.console.pipestreams = true invoke runConsole and check the console output. if you cannot figure it out, pls provide the console output and your configuration file. if it runs ok with runConsole but not with a service then check if the work dir is correctly set in the config or path to java or user rights. pls remember...
-
powershell can be easily run from a batch file. see for example: https://stackoverflow.com/questions/19335004/how-to-run-a-powershell-script-from-a-batch-file
-
thanks for the log. it shows that we have a conflict between yajsw, prometheus, wildfly and the way java's java.util.logging.manager works. if you add the prometheus agent to wildfly/bin/standalone.bat "%JAVA%" -javaagent:../jmx_prometheus_javaagent-0.19.0.jar=9097:../prometheus_config.yaml %JAVA_OPTS% ^ you get the same error: ERROR: WFLYCTL0013: Operation ("parallel-extension-add") failed - address: ([]) java.lang.RuntimeException: WFLYCTL0079: Failed initializing module org.jboss.as.logging but,...
-
as stated it is not a good idea to have daemons run off a network drive. especially not for java jars or for logging. I have often seen degraded performance of the application and random "class not found exceptions". did you try out the provided yajsw update ? could you pls provide a stack trace of when it hangs. -- Ron
-
as stated pls post the log files of when the application is crashing. the pipestreams property would not resolve the issue, it is for additional logging.
-
thanks for the feedback. this could be a java issue: https://bugs.openjdk.org/browse/JDK-6628575 working with network drives is generally not recommended, see; https://stackoverflow.com/questions/46720279/tomcat-application-hangs-when-accessing-a-nfs-mount I have changed yajsw to use tryLock(0,0,false) instead of tryLock() attached are the updated libs. pls replace these in your yajsw installation and let me know if this solves the issue. -- Ron
-
thanks for the feedback. this could be a java issue: https://bugs.openjdk.org/browse/JDK-6628575 working network drives is generally not recommended, see; https://stackoverflow.com/questions/46720279/tomcat-application-hangs-when-accessing-a-nfs-mount I have changed yajsw to use tryLock(0,0,false) instead of tryLock() attached are the updated libs. pls replace these in your yajsw installation and let me know if this solves the issue. -- Ron
-
for some reason after creation of the log file the wrapper seems to hang. if the log file cannot be created due to permissions, an exception is thrown and "problematic code part" is not executed. it works for me, so there must be an issue either with user rights or some OS specific issue. pls try the following: 1. when it hangs get a stacktrace using jstack (is in the jdk folder) and post it. 2. try changing the configuration: * remove wrapper.logfile.rollmode * remove YYYYMMDD_ROLLNUM in logfile...
-
hello, pls add to the configuration: wrapper.console.pipestreams = true change the config: (remove "\n"): wrapper.logfile.format=LPTM run startConsole and post the complete output of the console. (evntl remove and private logs such as passwords) -- Ron
-
new release: yajsw-stable-13.10
-
release 13.10
-
Logging not substituting variables
-
release 13.10
1 >