[jira] [Commented] (DAEMON-447) Allow to rotate stdout and stderr redirected logs
[
https://issues.apache.org/jira/browse/DAEMON-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847313#comment-17847313
]
Mark Thomas commented on DAEMON-447:
Note: DAEMON-213 has a link to a potential alternative suggestion
> Allow to rotate stdout and stderr redirected logs
> --
>
> Key: DAEMON-447
> URL: https://issues.apache.org/jira/browse/DAEMON-447
> Project: Commons Daemon
> Issue Type: Improvement
> Components: prunsrv
>Affects Versions: 1.3.0, 1.3.1
> Environment: Windows 10; WIndows Server 2016
>Reporter: Ivan Pedruzzi
>Priority: Major
>
> We have a large legacy web application which makes use of System.out.println
> to print errors.
> Our Tomcat 9 is configured to redirect stdout to file using switch --StdOut
> In some peculiar conditions our web application can print a very large amount
> error which end up in the log file and can quickly fill the hard drive,
> crashing the system.
> Looking at the code in prunsrv.c it is possible to implement a simple
> rotation policy which would limit the size of the log from stdout to a
> configurable number of bytes.
> Piggy backing on the worker thread "eventThread", when the log file size is
> above a configurable threshold (new option StdOutFileMaxSize) we could make
> a copy of the log and truncate the file.
> To enable the rotation for the redirects, we would need 2 options:
> --Rotate
> --StdOutFileMaxSize
> These could be used for both stderr and stdout or split in dedicated options
>
> Here is the worked altered with my change. In my local tests it behaves as I
> expect.
> DWORD WINAPI eventThread(LPVOID lpParam)
> {
> DWORD dwRotateCnt = SO_LOGROTATE;
> for (;;) {
> DWORD dw = WaitForSingleObject(gSignalEvent, 1000);
> if (dw == WAIT_TIMEOUT) {
> /* Do process maintenance */
> if (SO_LOGROTATE != 0 && --dwRotateCnt == 0) {
> /* Perform log rotation. */
>
> /* START CHANGE */
>
> __int64 MAX_Mbytes = SO_STDOUTFILEMAXSIZE;
> struct _stat64 fileInfo;
> if (gStdwrap.szStdOutFilename
> && gStdwrap.fpStdOutFile
> && _fstat64(_fileno(gStdwrap.fpStdOutFile), ) == > 0
> && fileInfo.st_size > MAX_Mbytes) {
> WCHAR sPath[SIZ_PATHLEN];
> lstrlcpyW(sPath, MAX_PATH, gStdwrap.szStdOutFilename);
> lstrlcatW(sPath, SIZ_PATHMAX, L"-backup.log");
> //Make a copy of current log before truncating it
> CopyFileW(gStdwrap.szStdOutFilename, sPath, FALSE);
> //close current handle
> fclose(gStdwrap.fpStdOutFile);
> //re-open file to truncate it
> FILE* tempHandle = _wfsopen(gStdwrap.szStdOutFilename,
> L"w", _SH_DENYNO);
> fclose(tempHandle);
>
> //re-open in append mode
> gStdwrap.fpStdOutFile =
> _wfsopen(gStdwrap.szStdOutFilename, L"a", _SH_DENYNO);
> _dup2(_fileno(gStdwrap.fpStdOutFile), 1);
> *stdout = *(gStdwrap.fpStdOutFile);
> }
> /* END CHANGE */
> dwRotateCnt = SO_LOGROTATE;
> }
> continue;
> }
> if (dw == WAIT_OBJECT_0 && gSignalValid) {
> if (!GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, 0)) {
> /* Invoke Thread dump */
> if (gWorker && _jni_startup)
> apxJavaDumpAllStacks(gWorker);
> }
> ResetEvent(gSignalEvent);
> continue;
> }
> break;
> }
> ExitThread(0);
> return 0;
> UNREFERENCED_PARAMETER(lpParam);
> }
>
>
>
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-213) procun log rotation support
[ https://issues.apache.org/jira/browse/DAEMON-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-213. Resolution: Duplicate > procun log rotation support > --- > > Key: DAEMON-213 > URL: https://issues.apache.org/jira/browse/DAEMON-213 > Project: Commons Daemon > Issue Type: Improvement > Components: Procrun >Affects Versions: 1.0.4, 1.0.5, 1.0.6 > Environment: os: winxp >Reporter: viola.lu >Priority: Minor > > currently, procun doesn't support log rotation. Should add an option -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DAEMON-463) Daemon fails to build on macOS with XCode 15.3
[
https://issues.apache.org/jira/browse/DAEMON-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-463.
Resolution: Fixed
> Daemon fails to build on macOS with XCode 15.3
> --
>
> Key: DAEMON-463
> URL: https://issues.apache.org/jira/browse/DAEMON-463
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
> Environment:
> Clang: 15.0.0 build 1500
> macOS: 14.4.1-arm64
> CLT: 15.3.0.0.1.1708646388
> Xcode: 15.3
> Rosetta 2: false
>Reporter: Sean Molenaar
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.4.0
>
>
> When building jsvc on macOS with XCode 15.3 (for Homebrew), the build fails
> with the following error:
>
> {code:java}
> jsvc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~ {code}
>
> For more details see:
> https://github.com/Homebrew/homebrew-core/actions/runs/8967899390/job/24626304630
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-464) struct sigaction function pointer causes build failures on LLVM 15+
[
https://issues.apache.org/jira/browse/DAEMON-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-464.
Resolution: Duplicate
It would have been sufficient to add a comment to DAEMON-463
> struct sigaction function pointer causes build failures on LLVM 15+
> ---
>
> Key: DAEMON-464
> URL: https://issues.apache.org/jira/browse/DAEMON-464
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
> Fix For: 1.4.0
>
>
> Issue on FreeBSD and macOS:
> {noformat}
> svc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-464) struct sigaction function pointer causes build failures on LLVM 15+
[
https://issues.apache.org/jira/browse/DAEMON-464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-464.
Fix Version/s: (was: 1.4.0)
Resolution: Duplicate
> struct sigaction function pointer causes build failures on LLVM 15+
> ---
>
> Key: DAEMON-464
> URL: https://issues.apache.org/jira/browse/DAEMON-464
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.4
>Reporter: Michael Osipov
>Assignee: Michael Osipov
>Priority: Major
>
> Issue on FreeBSD and macOS:
> {noformat}
> svc-unix.c:1311:20: error: incompatible function pointer types assigning to
> 'void (*)(int)' from 'void (int, siginfo_t *, void *)' (aka 'void (int,
> struct __siginfo *, void *)') [-Wincompatible-function-pointer-types]90
> act.sa_handler = controller;91 ^ ~~
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-461) Improve "Path to executable:" label on service manager General tab
[ https://issues.apache.org/jira/browse/DAEMON-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-461. Fix Version/s: 1.4.0 Resolution: Fixed > Improve "Path to executable:" label on service manager General tab > -- > > Key: DAEMON-461 > URL: https://issues.apache.org/jira/browse/DAEMON-461 > Project: Commons Daemon > Issue Type: Improvement > Components: Procrun >Affects Versions: 1.3.4 >Reporter: Bill Stewart >Priority: Trivial > Fix For: 1.4.0 > > > The service manager configuration dialog's General tab has "Path to > executable:" as the label for the service command line. This label is > imprecise and should really say "Command line:" or "Service start command > line:" or something similar. Simply saying "Path to executable:" is imprecise > because it implies that the string contains only a file path rather than the > command line being used to start the service. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DAEMON-460) High CPU usage in prunsrv.exe since Daemon 1.3.3
[ https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846325#comment-17846325 ] Mark Thomas commented on DAEMON-460: This is likely caused by this PR [https://github.com/apache/commons-daemon/pull/64] but I don't see any obvious cause. I can't repeat this issue with Tomcat - my default test application for any Daemon issue. Please provide the simplest possible test case that demonstrates this issue. > High CPU usage in prunsrv.exe since Daemon 1.3.3 > > > Key: DAEMON-460 > URL: https://issues.apache.org/jira/browse/DAEMON-460 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.3 >Reporter: Japie vd Linde >Priority: Major > Attachments: EspRun-Service-Log.2023-06-05.log, > image-2023-05-31-09-31-21-485.png, image-2023-06-05-13-38-38-435.png > > > When using the --StopTimeout=30 parameter on service using prunsrv the CPU > usage is reported as very high on Windows. Rolling back to older prunsrv > seems to resolve the problem. > !image-2023-05-31-09-31-21-485.png! > What could be the possible causes for this problem? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DAEMON-431) prunsrv crashes when stopping most windows versions
[ https://issues.apache.org/jira/browse/DAEMON-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-431. Resolution: Cannot Reproduce No further information provided after an extended period of time. > prunsrv crashes when stopping most windows versions > --- > > Key: DAEMON-431 > URL: https://issues.apache.org/jira/browse/DAEMON-431 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.2.4 > Environment: windows 10 fully patched. >Reporter: scott williams >Priority: Major > > Crashes when stopping every time. This is from win10 fully patched, but also > crashes on server 2012 and 2016 older patched. > > Faulting application name: wildfly-service.exe, version: 1.2.4.0, time stamp: > 0x600011df > Faulting module name: ntdll.dll, version: 10.0.19041.789, time stamp: > 0x4f929756 > Exception code: 0xc374 > Fault offset: 0x000ff099 > Faulting process id: 0x14d4 > Faulting application start time: 0x01d6ff2eb6330c32 > Faulting application path: C:\web\bin\service\amd64\wildfly-service.exe > Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll > Report Id: f2389cdb-df37-4a9c-b862-4399161457ea > Faulting package full name: > Faulting package-relative application ID: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DAEMON-449) Prunsrv fails to stop Open Liberty Windows service
[
https://issues.apache.org/jira/browse/DAEMON-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-449.
Resolution: Invalid
Given the lack of update for an extended period of time, I am assuming the
issue was indeed that the batch file was exiting before the service was fully
started.
If this is not the case, feel free to re-open but you'll need to provide a
minimal test case that demonstrates the issue.
> Prunsrv fails to stop Open Liberty Windows service
> --
>
> Key: DAEMON-449
> URL: https://issues.apache.org/jira/browse/DAEMON-449
> Project: Commons Daemon
> Issue Type: Bug
> Components: prunsrv
>Affects Versions: 1.2.2
> Environment: I don't think the Windows version matters, but I am
> using:
> Microsoft Windows [Version 10.0.19044.2006]
>Reporter: Jim Blye
>Priority: Major
> Attachments: commons-daemon.2022-09-28.log,
> commons-daemon.2022-09-28_afterKillingServer.log, server.bat
>
>
> < *Update* . The reason the stop fails is because the start hasn't finished.
> Prunsrv isn't waiting for the start to finish. So in the Windows services
> panel, the service appears to be started. If you then click stop, it hangs
> for a few minutes and fails to stop. The state at this point in the Windows
> services is "Stopping". So you have to manually stop the process. >
> When Prunsrv is used to register Open Liberty
> ([https://openliberty.io|https://openliberty.io/]) as a Windows Service,
> stopping the service hangs randomly.
> *To recreate the problem:*
> 1) Download open liberty ~300MB
>
> [https://public.dhe.ibm.com/ibmdl/export/pub/software/openliberty/runtime/release/22.0.0.10/openliberty-22.0.0.10.zip]
> Alternatively, you could use just the liberty kernel ~10MB
>
> [https://public.dhe.ibm.com/ibmdl/export/pub/software/openliberty/runtime/release/22.0.0.10/openliberty-kernel-22.0.0.10.zip]
> 2) md C:\temp\openliberty
> unzip openliberty-22.0.0.10.zip into C:\temp\openliberty
> 3) cd C:\temp\openliberty\wlp\bin
> 4) Run these two commands to make sure the server runs and to initialize
> the environment:
> server start
> server stop
> 5) Register liberty as a service (parameter is case sensitive). The
> following command is used to invoke prunsrv to register the service using the
> default name of defaultServer
> server registerWinService
> 6) Open the windows "services" app (services.msc). Start and stop the
> service until the stop hangs. It usually doesn't take more than a couple of
> tries.
>
> *Details*
> The *server.bat* script registers the service like this:
> "C:\temp\openliberty\wlp\bin\tools\win\prunsrv.exe" //IS//defaultServer
> --Startup=manual --DisplayName="defaultServer" --Description="Open Liberty"
> ++DependsOn=Tcpip
> --LogPath="C:\temp\openliberty\wlp\usr\servers\defaultServer\logs"
> --StdOutput=auto --StdError=auto --StartMode=exe
> --StartPath="C:\temp\openliberty\wlp"
> --StartImage="C:\temp\openliberty\wlp\bin\server.bat"
> ++StartParams=start#defaultServer --StopMode=exe
> --StopPath="C:\temp\openliberty\wlp" --StopImage="C:\temp\wlp\bin\server.bat"
> ++StopParams=stop#defaultServer --ServiceUser=LocalSystem
> After registering the service you can look at its properties. You will see:
> Path to executable:
> C:\temp\openliberty\wlp\bin\tools\win\prunsrv.exe //RS//defaultServer
> When I (and many of our customers) try to stop the service, it hangs. At
> that point, the server, named defaultServer is still up and running. I can
> send commands to the server. For instance, I can execute a "server dump"
> command. This sends the "dump" command to the server, and the server writes
> information to a file. I can also stop the server by executing "server
> stop". This sends the "stop" command to the server which causes the server
> to stop. When the server stops, the hanging Windows service stops as well.
> I have attached a *server.bat* which adds --LogLevel Debug to the prunsrv
> commands and also *commons-daemon.2022-09-28.log* which demonstrates the
> problem. It shows registering, starting, and stopping the service. Finally,
> I uploaded {*}commons-daemon.2022-09-28_afterKillingServer.log{*}, which is a
> continuation of the other log file which shows the result of issuing the
> server stop command to stop the server.
> Thanks for looking at this.
> Jim Blye
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-457) Tomcat9.exe crash in windows server 2016 and 2019 while updating service.
[
https://issues.apache.org/jira/browse/DAEMON-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-457.
Resolution: Cannot Reproduce
This can be re-opened if steps are provided to recreate this issue on a clean
install of any currently supported Windows OS.
> Tomcat9.exe crash in windows server 2016 and 2019 while updating service.
> -
>
> Key: DAEMON-457
> URL: https://issues.apache.org/jira/browse/DAEMON-457
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.3
> Environment: Windows Server 2016 and 2019
>Reporter: Denish Kothadiya
>Priority: Critical
> Attachments: logs.zip
>
>
> Tomcat9.exe crash in windows server 2016 and 2019 while updating service. We
> have observer issue from Tomcat 9 version 9.0.70 and above. It was working
> fine with Tomcat version 9.0.69.
> Environment details:
> OS: Windows server 2016 and 2019
> Disk space: More than 80 GB
> RAM: 8GB and more
> VC Redist x64: 14.29.30139.0
> Tomcat service details:
> JvmMs=512
> JvmMx=3076
> After creating tomcat service, We run below command to update service with
> JavaOption9
> {code}
> Tomcat9 //US//Tomcat9 ++JvmOptions9
> --add-opens=java.base/java.lang.reflect=ALL-UNNAMED#--add-opens=java.base/jdk.internal.reflect=ALL-UNNAMED#--add-opens=java.base/java.lang.annotation=ALL-UNNAMED#--add-opens=java.base/java.util.Date=ALL-UNNAMED#--add-opens=java.base/java.io=ALL-UNNAMED#--add-opens=java.base/java.util=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED#--add-opens=java.base/java.math=ALL-UNNAMED#--add-opens=java.base/java.text=ALL-UNNAMED#--add-opens=java.base/javax.net.ssl=ALL-UNNAMED#--add-opens=java.base/java.time=ALL-UNNAMED
> {code}
> Above command fails with below crash in EventViewer:
> Faulting application name: tomcat9.exe, version: 1.3.3.0, time stamp:
> 0x637e7ca5
> Faulting module name: ntdll.dll, version: 10.0.17763.2237, time stamp:
> 0x65420ea4
> Exception code: 0xc374
> Fault offset: 0x000fa979
> Faulting process id: 0x298
> Faulting application start time: 0x01d967f65ac00dce
> Faulting application path: C:\Program Files\DELL\WMS\Tomcat-9\bin\tomcat9.exe
> Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
> Report Id: 28b620b5-f3a0-40c3-99ae-962cab71bab8
> Faulting package full name:
> Please let me know if you need any more details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-460) High CPU usage in prunsrv.exe since Daemon 1.3.4
[ https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17729285#comment-17729285 ] Mark Thomas commented on DAEMON-460: Have you explicitly tested this with 1.3.2 and confirmed that 1.3.2 does not exhibit this behaviour? > High CPU usage in prunsrv.exe since Daemon 1.3.4 > > > Key: DAEMON-460 > URL: https://issues.apache.org/jira/browse/DAEMON-460 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.3 >Reporter: Japie vd Linde >Priority: Major > Attachments: EspRun-Service-Log.2023-06-05.log, > image-2023-05-31-09-31-21-485.png > > > When using the --StopTimeout=30 parameter on service using prunsrv the CPU > usage is reported as very high on Windows. Rolling back to older prunsrv > seems to resolve the problem. > !image-2023-05-31-09-31-21-485.png! > What could be the possible causes for this problem? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DAEMON-460) High CPU usage in prunsrv.exe since Daemon 1.3.4
[ https://issues.apache.org/jira/browse/DAEMON-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas updated DAEMON-460: --- Fix Version/s: (was: 1.3.4) > High CPU usage in prunsrv.exe since Daemon 1.3.4 > > > Key: DAEMON-460 > URL: https://issues.apache.org/jira/browse/DAEMON-460 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.4 >Reporter: Japie vd Linde >Priority: Major > Attachments: image-2023-05-31-09-31-21-485.png > > > When using the --StopTimeout=30 parameter on service using prunsrv the CPU > usage is reported as very high on Windows. Rolling back to older prunsrv > seems to resolve the problem. > !image-2023-05-31-09-31-21-485.png! > What could be the possible causes for this problem? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (DAEMON-458) The changes in DAEMON-446 cause existing DependsOn values to be removed
[
https://issues.apache.org/jira/browse/DAEMON-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas updated DAEMON-458:
---
Component/s: Procrun
> The changes in DAEMON-446 cause existing DependsOn values to be removed
> ---
>
> Key: DAEMON-458
> URL: https://issues.apache.org/jira/browse/DAEMON-458
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Brian Andle
>Priority: Major
> Fix For: 1.3.4
>
>
> As part of DAEMON-446 a regression was introduced that causes existing
> service DependsOn services to be removed when working with the //US option.
>
> Replication:
> Run:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=MyService
> --DisplayName=MyService
> sc config MyService depend=Tcpip/Afd/Dhcp {code}
> View the services and note that *MyService* depends on Dhcp (the sc config
> command is being used to represent a separate script call)
> Now run:
> {code:java}
> prunsrv.exe //US/MyService --Startup=manual {code}
> View the services and note that MyService no longer depends on Dhcp
> The offending code appears to be the following in service.c:
> {code:java}
> /* Add the mandatory dependencies */
> if (lpDependencies) {
> lpDependencies = apxMultiSzCombine(NULL, lpDependencies,
> L"Tcpip\0Afd\0", NULL);
> } else {
> lpDependencies = L"Tcpip\0Afd\0";
> }{code}
> Which means if DependsOn isn't defined we'll always pass down Tcpip and Afd,
> vs the NULL that happened before. Wiping existing custom dependancies out.
> I didn't test it but this code may not work properly with the – vs ++ logic
> defined under [https://commons.apache.org/proper/commons-daemon/procrun.html]
> The DAEMON-446 ticket talks about --DependsOn (full replace) although I only
> see ++Depends on documented, so maybe DAEMON-446 was actually invalid to
> begin with?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-459) Restart only works once (regression)
[
https://issues.apache.org/jira/browse/DAEMON-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-459.
Fix Version/s: 1.3.4
Resolution: Fixed
Thanks for the test case.
> Restart only works once (regression)
>
>
> Key: DAEMON-459
> URL: https://issues.apache.org/jira/browse/DAEMON-459
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.3
>Reporter: Klaus Malorny
>Priority: Major
> Fix For: 1.3.4
>
> Attachments: ApacheDaemonBug.zip
>
>
> For certain functions, especially code updates, we rely on the ability to
> restart the child process. This seems to work only once. On the subsequent
> attempt, the child process hangs.
> I tracked down the problem and found out that the problem is within the
> {{jsvc-unix.c}} file. The {{main_reload}} function is called to send the
> signal to itself, but this does not happen. In the first restart, the
> {{controlled}} variable holds the value of 0. This works by chance, as the
> signal is sent to the parent, which sends it back to the child. In the second
> attempt, the variable holds the PID of the previous child, thus the signal is
> sent to a no longer existing process.
> The {{controlled}} variable is used both by the parent and the child process.
> In earlier versions of the file, the child process determines its own PID by
> using the {{getpid}} system function. This call has been – likely
> accidentally – removed in version 1.3.3 or earlier. Thus, the variable
> contains the parent's value before the fork which has created the child.
> The solution is simple: in the function {{{}child{}}}, add
> {{ controlled = getpid ();}}
> between the {{sigaction}} calls and the {{log_debug ("Waiting for a signal to
> be delivered")}} call (line 913 in my copy of the file), i.e.
> {{ ...}}
> {{ memset(, '\0', sizeof(act));}}
> {{ act.sa_handler = handler;}}
> {{ sigemptyset(_mask);}}
> {{ act.sa_flags = SA_RESTART | SA_NOCLDSTOP;}}
> {{ sigaction(SIGHUP, , NULL);}}
> {{ sigaction(SIGUSR1, , NULL);}}
> {{ sigaction(SIGUSR2, , NULL);}}
> {{ sigaction(SIGTERM, , NULL);}}
> {{ sigaction(SIGINT, , NULL);}}
> {{ *controlled = getpid ();*}}
> {{ log_debug("Waiting for a signal to be delivered");}}
> {{ create_tmp_file(args);}}
> {{ while (!stopping) {}}
> {{ ...}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-457) Tomcat9.exe crash in windows server 2016 and 2019 while updating service.
[
https://issues.apache.org/jira/browse/DAEMON-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17719457#comment-17719457
]
Mark Thomas commented on DAEMON-457:
I have followed the provided steps and am unable to recreate the issue on a
fully patched Windows 2019 server. I also tried running the same command
multiple times (~20) and generated a really long list of Java 9 options in the
registry without any error being reported.
It looks very much like there is something else about the environment on the
affected machines that is triggering the issue.
More detail about the issue when it happens (Does it happen for any option? Is
it related to the length of the added value? Is it related to the total length
of the new value? etc.) may help us narrow down where the problem may be.
> Tomcat9.exe crash in windows server 2016 and 2019 while updating service.
> -
>
> Key: DAEMON-457
> URL: https://issues.apache.org/jira/browse/DAEMON-457
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.3
> Environment: Windows Server 2016 and 2019
>Reporter: Denish Kothadiya
>Priority: Critical
> Attachments: logs.zip
>
>
> Tomcat9.exe crash in windows server 2016 and 2019 while updating service. We
> have observer issue from Tomcat 9 version 9.0.70 and above. It was working
> fine with Tomcat version 9.0.69.
> Environment details:
> OS: Windows server 2016 and 2019
> Disk space: More than 80 GB
> RAM: 8GB and more
> VC Redist x64: 14.29.30139.0
> Tomcat service details:
> JvmMs=512
> JvmMx=3076
> After creating tomcat service, We run below command to update service with
> JavaOption9
> {code}
> Tomcat9 //US//Tomcat9 ++JvmOptions9
> --add-opens=java.base/java.lang.reflect=ALL-UNNAMED#--add-opens=java.base/jdk.internal.reflect=ALL-UNNAMED#--add-opens=java.base/java.lang.annotation=ALL-UNNAMED#--add-opens=java.base/java.util.Date=ALL-UNNAMED#--add-opens=java.base/java.io=ALL-UNNAMED#--add-opens=java.base/java.util=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED#--add-opens=java.base/java.math=ALL-UNNAMED#--add-opens=java.base/java.text=ALL-UNNAMED#--add-opens=java.base/javax.net.ssl=ALL-UNNAMED#--add-opens=java.base/java.time=ALL-UNNAMED
> {code}
> Above command fails with below crash in EventViewer:
> Faulting application name: tomcat9.exe, version: 1.3.3.0, time stamp:
> 0x637e7ca5
> Faulting module name: ntdll.dll, version: 10.0.17763.2237, time stamp:
> 0x65420ea4
> Exception code: 0xc374
> Fault offset: 0x000fa979
> Faulting process id: 0x298
> Faulting application start time: 0x01d967f65ac00dce
> Faulting application path: C:\Program Files\DELL\WMS\Tomcat-9\bin\tomcat9.exe
> Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
> Report Id: 28b620b5-f3a0-40c3-99ae-962cab71bab8
> Faulting package full name:
> Please let me know if you need any more details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-459) Restart only works once (regression)
[
https://issues.apache.org/jira/browse/DAEMON-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17717125#comment-17717125
]
Mark Thomas commented on DAEMON-459:
I'm testing this with Tomcat and I am unable to repeat the problem described.
`kill -HUP ` works as expected for repeated invocations. Note that
if you request a restart within 60s of the last start, there will be a delay of
60s between the service stopping and it restarting (to prevent looping).
Please provide the steps to recreate this issue using the current source code.
Running with -debug is useful to see exactly what is going on during a restart.
> Restart only works once (regression)
>
>
> Key: DAEMON-459
> URL: https://issues.apache.org/jira/browse/DAEMON-459
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.3
>Reporter: Klaus Malorny
>Priority: Major
>
> For certain functions, especially code updates, we rely on the ability to
> restart the child process. This seems to work only once. On the subsequent
> attempt, the child process hangs.
> I tracked down the problem and found out that the problem is within the
> {{jsvc-unix.c}} file. The {{main_reload}} function is called to send the
> signal to itself, but this does not happen. In the first restart, the
> {{controlled}} variable holds the value of 0. This works by chance, as the
> signal is sent to the parent, which sends it back to the child. In the second
> attempt, the variable holds the PID of the previous child, thus the signal is
> sent to a no longer existing process.
> The {{controlled}} variable is used both by the parent and the child process.
> In earlier versions of the file, the child process determines its own PID by
> using the {{getpid}} system function. This call has been – likely
> accidentally – removed in version 1.3.3 or earlier. Thus, the variable
> contains the parent's value before the fork which has created the child.
> The solution is simple: in the function {{{}child{}}}, add
> {{ controlled = getpid ();}}
> between the {{sigaction}} calls and the {{log_debug ("Waiting for a signal to
> be delivered")}} call (line 913 in my copy of the file), i.e.
> {{ ...}}
> {{ memset(, '\0', sizeof(act));}}
> {{ act.sa_handler = handler;}}
> {{ sigemptyset(_mask);}}
> {{ act.sa_flags = SA_RESTART | SA_NOCLDSTOP;}}
> {{ sigaction(SIGHUP, , NULL);}}
> {{ sigaction(SIGUSR1, , NULL);}}
> {{ sigaction(SIGUSR2, , NULL);}}
> {{ sigaction(SIGTERM, , NULL);}}
> {{ sigaction(SIGINT, , NULL);}}
> {{ *controlled = getpid ();*}}
> {{ log_debug("Waiting for a signal to be delivered");}}
> {{ create_tmp_file(args);}}
> {{ while (!stopping) {}}
> {{ ...}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-459) Restart only works once (regression)
[
https://issues.apache.org/jira/browse/DAEMON-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716861#comment-17716861
]
Mark Thomas commented on DAEMON-459:
The regression appears to have been introduced in the fix for DAEMON-339.
https://github.com/apache/commons-daemon/commit/718787b4068f1419bf24e6851ff8138e92ddb7cb
> Restart only works once (regression)
>
>
> Key: DAEMON-459
> URL: https://issues.apache.org/jira/browse/DAEMON-459
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.3.3
>Reporter: Klaus Malorny
>Priority: Major
>
> For certain functions, especially code updates, we rely on the ability to
> restart the child process. This seems to work only once. On the subsequent
> attempt, the child process hangs.
> I tracked down the problem and found out that the problem is within the
> {{jsvc-unix.c}} file. The {{main_reload}} function is called to send the
> signal to itself, but this does not happen. In the first restart, the
> {{controlled}} variable holds the value of 0. This works by chance, as the
> signal is sent to the parent, which sends it back to the child. In the second
> attempt, the variable holds the PID of the previous child, thus the signal is
> sent to a no longer existing process.
> The {{controlled}} variable is used both by the parent and the child process.
> In earlier versions of the file, the child process determines its own PID by
> using the {{getpid}} system function. This call has been – likely
> accidentally – removed in version 1.3.3 or earlier. Thus, the variable
> contains the parent's value before the fork which has created the child.
> The solution is simple: in the function {{{}child{}}}, add
> {{ controlled = getpid ();}}
> between the {{sigaction}} calls and the {{log_debug ("Waiting for a signal to
> be delivered")}} call (line 913 in my copy of the file), i.e.
> {{ ...}}
> {{ memset(, '\0', sizeof(act));}}
> {{ act.sa_handler = handler;}}
> {{ sigemptyset(_mask);}}
> {{ act.sa_flags = SA_RESTART | SA_NOCLDSTOP;}}
> {{ sigaction(SIGHUP, , NULL);}}
> {{ sigaction(SIGUSR1, , NULL);}}
> {{ sigaction(SIGUSR2, , NULL);}}
> {{ sigaction(SIGTERM, , NULL);}}
> {{ sigaction(SIGINT, , NULL);}}
> {{ *controlled = getpid ();*}}
> {{ log_debug("Waiting for a signal to be delivered");}}
> {{ create_tmp_file(args);}}
> {{ while (!stopping) {}}
> {{ ...}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-445) Changes of DAEMON-441 cause trouble with empty env vars
[
https://issues.apache.org/jira/browse/DAEMON-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-445.
Resolution: Cannot Reproduce
I have tried the registry approach to create an empty environment variable on
all currently supported versions of Windows without success. I am therefore
resolving this issue as cannot reproduce.
I have no objections to this issue being re-opened if steps are provided to
recreate it on a fully patched installation of any currently supported (by
Microsoft) Windows operating system.
> Changes of DAEMON-441 cause trouble with empty env vars
> ---
>
> Key: DAEMON-445
> URL: https://issues.apache.org/jira/browse/DAEMON-445
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Alexander Fischer
>Priority: Major
> Attachments:
> 0001-Fix-DAEMON-445.-Fix-processing-of-environment-variab.patch
>
>
> The changes done via DAEMON-441, namely
> [https://github.com/apache/commons-daemon/commit/97b31058ecf5e4dc202188d8e8917f6caa90dcfc#diff-e7f9bbe0d9947378640c1e1c91d8dc72c93e6d1034218458158a1cc43f2f3b9fR278]
> lead to a failing service installation in case the environment variable
> exists but has no value.
> In my use case the supported environment variables are explicitly set empty
> if defaults shall be used. This is done to avoid interference with
> environment variables which may be set by the caling process.
> In such a case example output is:
> {noformat}
> [2022-06-29 11:32:11] [error] [10552] Error getting environment variable
> PR_LibraryPath
> [2022-06-29 11:32:11] [warn] [10552] Failed to grant service user '.\user'
> write permissions to log path 'C:\Windows\system32\LogFiles\Apache' due to
> error '19: The media is write protected.'
> {noformat}
> while the environment is set
> {noformat}
> PR_DESCRIPTION: tomcat-service description
> PR_DISPLAYNAME: tomcat-service
> PR_INSTALL: C:\apache-tomcat\bin\tomcat9.exe
> PR_SERVICEUSER: .\hidden
> PR_SERVICEPASSWORD: hidden
> PR_STARTUP: auto
> PR_CLASSPATH:
> C:\apache-tomcat/bin/bootstrap.jar;C:\apache-tomcat/bin/tomcat-juli.jar;
> PR_JAVA_HOME: C:\jdk
> PR_JVM: C:\jdk\bin\server\jvm.dll
> PR_JVMMS: 256
> PR_JVMMX: 3072
> PR_JVMOPTIONS:
> -Dcatalina.base=C:\tomcat-service;-Dcatalina.home=C:\apache-tomcat;-Djava.io.tmpdir=C:\tomcat-service/temp;
> PR_ENVIRONMENT:
> PATH='C:\Windows;C:\Windows\System32;C:\Windows\System32\Wbem;C:\apache-tomcat\bin'
> PR_LIBRARYPATH: C:\apache-tomcat/bin
> PR_STARTCLASS: org.apache.catalina.startup.Bootstrap
> PR_STARTMETHOD:
> PR_STARTPARAMS: start
> PR_STARTMODE: jvm
> PR_STARTPATH: C:\tomcat-service
> PR_STOPCLASS: org.apache.catalina.startup.Bootstrap
> PR_STOPMETHOD:
> PR_STOPPARAMS: stop
> PR_STOPMODE: jvm
> PR_STOPPATH: C:\tomcat-service
> PR_STOPTIMEOUT: 60
> PR_LOGJNIMESSAGES: 0
> PR_LOGLEVEL: Info
> PR_LOGPATH: C:\Logs\tomcat-service
> PR_LOGPREFIX: tomcat-service
> PR_STDERROR: auto
> PR_STDOUTPUT: auto
> PR_DEPENDSON: postgresql-x64-11;
> {noformat}
> Means, the environment variables PR_STOPMETHOD, PR_LIBRARYPATH and
> PR_STARTMETHOD are defined but empty.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-315) Prunsrv should allow stop method with no arguments
[ https://issues.apache.org/jira/browse/DAEMON-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-315. Resolution: Works for Me The current API has such a method > Prunsrv should allow stop method with no arguments > -- > > Key: DAEMON-315 > URL: https://issues.apache.org/jira/browse/DAEMON-315 > Project: Commons Daemon > Issue Type: Improvement > Components: Procrun >Affects Versions: 1.0.15 >Reporter: Jens Reimann >Priority: Major > > Many libraries already provide a static stop method which accepts no > arguments. > Procsrv should honor this and simply allow such methods -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DAEMON-458) The changes in DAEMON-446 cause existing DependsOn values to be removed
[
https://issues.apache.org/jira/browse/DAEMON-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-458.
Fix Version/s: 1.3.4
Resolution: Fixed
It turns out pretty much all of the plumbing to get this working was in place,
I just had to switch the code to use the existing service dependencies in the
registry rather than maintaining its own, separate registry entry.
> The changes in DAEMON-446 cause existing DependsOn values to be removed
> ---
>
> Key: DAEMON-458
> URL: https://issues.apache.org/jira/browse/DAEMON-458
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Brian Andle
>Priority: Major
> Fix For: 1.3.4
>
>
> As part of DAEMON-446 a regression was introduced that causes existing
> service DependsOn services to be removed when working with the //US option.
>
> Replication:
> Run:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=MyService
> --DisplayName=MyService
> sc config MyService depend=Tcpip/Afd/Dhcp {code}
> View the services and note that *MyService* depends on Dhcp (the sc config
> command is being used to represent a separate script call)
> Now run:
> {code:java}
> prunsrv.exe //US/MyService --Startup=manual {code}
> View the services and note that MyService no longer depends on Dhcp
> The offending code appears to be the following in service.c:
> {code:java}
> /* Add the mandatory dependencies */
> if (lpDependencies) {
> lpDependencies = apxMultiSzCombine(NULL, lpDependencies,
> L"Tcpip\0Afd\0", NULL);
> } else {
> lpDependencies = L"Tcpip\0Afd\0";
> }{code}
> Which means if DependsOn isn't defined we'll always pass down Tcpip and Afd,
> vs the NULL that happened before. Wiping existing custom dependancies out.
> I didn't test it but this code may not work properly with the – vs ++ logic
> defined under [https://commons.apache.org/proper/commons-daemon/procrun.html]
> The DAEMON-446 ticket talks about --DependsOn (full replace) although I only
> see ++Depends on documented, so maybe DAEMON-446 was actually invalid to
> begin with?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-458) The changes in DAEMON-446 cause existing DependsOn values to be removed
[
https://issues.apache.org/jira/browse/DAEMON-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714583#comment-17714583
]
Mark Thomas commented on DAEMON-458:
It is fairly simple to fix things so dependencies can be managed either via 'sc
config ...' or via 'DependsOn'. I'l commit a fix shortly that does that. Note
that once 'DependsOn' has been used with a service, any value set will override
anything set via `sc config` the next time '//US' is used.
Being able to 'sc config ...' and 'DependsOn' interchangeably looks to be a lot
trickier. I'm not at the point yet where I think the solution is documenting
that this isn't supported but it is certainly a possibility.
> The changes in DAEMON-446 cause existing DependsOn values to be removed
> ---
>
> Key: DAEMON-458
> URL: https://issues.apache.org/jira/browse/DAEMON-458
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Brian Andle
>Priority: Major
>
> As part of DAEMON-446 a regression was introduced that causes existing
> service DependsOn services to be removed when working with the //US option.
>
> Replication:
> Run:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=MyService
> --DisplayName=MyService
> sc config MyService depend=Tcpip/Afd/Dhcp {code}
> View the services and note that *MyService* depends on Dhcp (the sc config
> command is being used to represent a separate script call)
> Now run:
> {code:java}
> prunsrv.exe //US/MyService --Startup=manual {code}
> View the services and note that MyService no longer depends on Dhcp
> The offending code appears to be the following in service.c:
> {code:java}
> /* Add the mandatory dependencies */
> if (lpDependencies) {
> lpDependencies = apxMultiSzCombine(NULL, lpDependencies,
> L"Tcpip\0Afd\0", NULL);
> } else {
> lpDependencies = L"Tcpip\0Afd\0";
> }{code}
> Which means if DependsOn isn't defined we'll always pass down Tcpip and Afd,
> vs the NULL that happened before. Wiping existing custom dependancies out.
> I didn't test it but this code may not work properly with the – vs ++ logic
> defined under [https://commons.apache.org/proper/commons-daemon/procrun.html]
> The DAEMON-446 ticket talks about --DependsOn (full replace) although I only
> see ++Depends on documented, so maybe DAEMON-446 was actually invalid to
> begin with?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-458) The changes in DAEMON-446 cause existing DependsOn values to be removed
[
https://issues.apache.org/jira/browse/DAEMON-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714527#comment-17714527
]
Mark Thomas commented on DAEMON-458:
Thanks for the report. I can repeat this issue. Procrun isn't taking into
account any changes that may have been made to the service configuration
outside of Procrun. I'll see if it is possible to do anything about that
although part of me is thinking that the service should either be managed using
procrun or externally to procrun and that a mix of both approaches is asking
for trouble to some extent.
Note that the '++' and '--' variations of 'DependsOn' both work as expected.
> The changes in DAEMON-446 cause existing DependsOn values to be removed
> ---
>
> Key: DAEMON-458
> URL: https://issues.apache.org/jira/browse/DAEMON-458
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Brian Andle
>Priority: Major
>
> As part of DAEMON-446 a regression was introduced that causes existing
> service DependsOn services to be removed when working with the //US option.
>
> Replication:
> Run:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=MyService
> --DisplayName=MyService
> sc config MyService depend=Tcpip/Afd/Dhcp {code}
> View the services and note that *MyService* depends on Dhcp (the sc config
> command is being used to represent a separate script call)
> Now run:
> {code:java}
> prunsrv.exe //US/MyService --Startup=manual {code}
> View the services and note that MyService no longer depends on Dhcp
> The offending code appears to be the following in service.c:
> {code:java}
> /* Add the mandatory dependencies */
> if (lpDependencies) {
> lpDependencies = apxMultiSzCombine(NULL, lpDependencies,
> L"Tcpip\0Afd\0", NULL);
> } else {
> lpDependencies = L"Tcpip\0Afd\0";
> }{code}
> Which means if DependsOn isn't defined we'll always pass down Tcpip and Afd,
> vs the NULL that happened before. Wiping existing custom dependancies out.
> I didn't test it but this code may not work properly with the – vs ++ logic
> defined under [https://commons.apache.org/proper/commons-daemon/procrun.html]
> The DAEMON-446 ticket talks about --DependsOn (full replace) although I only
> see ++Depends on documented, so maybe DAEMON-446 was actually invalid to
> begin with?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (DAEMON-458) The changes in DAEMON-446 cause existing DependsOn values to be removed
[ https://issues.apache.org/jira/browse/DAEMON-458 ]
Mark Thomas deleted comment on DAEMON-458:
was (Author: markt):
I see a couple of issues with the management of dependencies as this point.
# There is no need to explicitly specify Tcpip and Afd - they get added
automatically.
# Changes made outside of procrun are lost the next time procrun makes a
change (the basis of this bug report).
Note: The use of '++' and '–' work as expected with the 'DependsOn' option.
> The changes in DAEMON-446 cause existing DependsOn values to be removed
> ---
>
> Key: DAEMON-458
> URL: https://issues.apache.org/jira/browse/DAEMON-458
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Brian Andle
>Priority: Major
>
> As part of DAEMON-446 a regression was introduced that causes existing
> service DependsOn services to be removed when working with the //US option.
>
> Replication:
> Run:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=MyService
> --DisplayName=MyService
> sc config MyService depend=Tcpip/Afd/Dhcp {code}
> View the services and note that *MyService* depends on Dhcp (the sc config
> command is being used to represent a separate script call)
> Now run:
> {code:java}
> prunsrv.exe //US/MyService --Startup=manual {code}
> View the services and note that MyService no longer depends on Dhcp
> The offending code appears to be the following in service.c:
> {code:java}
> /* Add the mandatory dependencies */
> if (lpDependencies) {
> lpDependencies = apxMultiSzCombine(NULL, lpDependencies,
> L"Tcpip\0Afd\0", NULL);
> } else {
> lpDependencies = L"Tcpip\0Afd\0";
> }{code}
> Which means if DependsOn isn't defined we'll always pass down Tcpip and Afd,
> vs the NULL that happened before. Wiping existing custom dependancies out.
> I didn't test it but this code may not work properly with the – vs ++ logic
> defined under [https://commons.apache.org/proper/commons-daemon/procrun.html]
> The DAEMON-446 ticket talks about --DependsOn (full replace) although I only
> see ++Depends on documented, so maybe DAEMON-446 was actually invalid to
> begin with?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-458) The changes in DAEMON-446 cause existing DependsOn values to be removed
[
https://issues.apache.org/jira/browse/DAEMON-458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714523#comment-17714523
]
Mark Thomas commented on DAEMON-458:
I see a couple of issues with the management of dependencies as this point.
# There is no need to explicitly specify Tcpip and Afd - they get added
automatically.
# Changes made outside of procrun are lost the next time procrun makes a
change (the basis of this bug report).
Note: The use of '++' and '–' work as expected with the 'DependsOn' option.
> The changes in DAEMON-446 cause existing DependsOn values to be removed
> ---
>
> Key: DAEMON-458
> URL: https://issues.apache.org/jira/browse/DAEMON-458
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.2, 1.3.3
>Reporter: Brian Andle
>Priority: Major
>
> As part of DAEMON-446 a regression was introduced that causes existing
> service DependsOn services to be removed when working with the //US option.
>
> Replication:
> Run:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=MyService
> --DisplayName=MyService
> sc config MyService depend=Tcpip/Afd/Dhcp {code}
> View the services and note that *MyService* depends on Dhcp (the sc config
> command is being used to represent a separate script call)
> Now run:
> {code:java}
> prunsrv.exe //US/MyService --Startup=manual {code}
> View the services and note that MyService no longer depends on Dhcp
> The offending code appears to be the following in service.c:
> {code:java}
> /* Add the mandatory dependencies */
> if (lpDependencies) {
> lpDependencies = apxMultiSzCombine(NULL, lpDependencies,
> L"Tcpip\0Afd\0", NULL);
> } else {
> lpDependencies = L"Tcpip\0Afd\0";
> }{code}
> Which means if DependsOn isn't defined we'll always pass down Tcpip and Afd,
> vs the NULL that happened before. Wiping existing custom dependancies out.
> I didn't test it but this code may not work properly with the – vs ++ logic
> defined under [https://commons.apache.org/proper/commons-daemon/procrun.html]
> The DAEMON-446 ticket talks about --DependsOn (full replace) although I only
> see ++Depends on documented, so maybe DAEMON-446 was actually invalid to
> begin with?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-457) Tomcat9.exe crash in windows server 2016 and 2019 while updating service.
[
https://issues.apache.org/jira/browse/DAEMON-457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17714221#comment-17714221
]
Mark Thomas commented on DAEMON-457:
This works for me with Tomcat 9.0.74.
Please provide detailed steps to reproduce this issue from a clean install of
the latest version of any currently supported version of Tomcat.
Without steps to reproduce, this issue will eventually gets resolved as "Cannot
reproduce".
> Tomcat9.exe crash in windows server 2016 and 2019 while updating service.
> -
>
> Key: DAEMON-457
> URL: https://issues.apache.org/jira/browse/DAEMON-457
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.3
> Environment: Windows Server 2016 and 2019
>Reporter: Denish Kothadiya
>Priority: Critical
> Attachments: logs.zip
>
>
> Tomcat9.exe crash in windows server 2016 and 2019 while updating service. We
> have observer issue from Tomcat 9 version 9.0.70 and above. It was working
> fine with Tomcat version 9.0.69.
> Environment details:
> OS: Windows server 2016 and 2019
> Disk space: More than 80 GB
> RAM: 8GB and more
> VC Redist x64: 14.29.30139.0
> Tomcat service details:
> JvmMs=512
> JvmMx=3076
> After creating tomcat service, We run below command to update service with
> JavaOption9
> {code}
> Tomcat9 //US//Tomcat9 ++JvmOptions9
> --add-opens=java.base/java.lang.reflect=ALL-UNNAMED#--add-opens=java.base/jdk.internal.reflect=ALL-UNNAMED#--add-opens=java.base/java.lang.annotation=ALL-UNNAMED#--add-opens=java.base/java.util.Date=ALL-UNNAMED#--add-opens=java.base/java.io=ALL-UNNAMED#--add-opens=java.base/java.util=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED#--add-opens=java.base/java.math=ALL-UNNAMED#--add-opens=java.base/java.text=ALL-UNNAMED#--add-opens=java.base/javax.net.ssl=ALL-UNNAMED#--add-opens=java.base/java.time=ALL-UNNAMED
> {code}
> Above command fails with below crash in EventViewer:
> Faulting application name: tomcat9.exe, version: 1.3.3.0, time stamp:
> 0x637e7ca5
> Faulting module name: ntdll.dll, version: 10.0.17763.2237, time stamp:
> 0x65420ea4
> Exception code: 0xc374
> Fault offset: 0x000fa979
> Faulting process id: 0x298
> Faulting application start time: 0x01d967f65ac00dce
> Faulting application path: C:\Program Files\DELL\WMS\Tomcat-9\bin\tomcat9.exe
> Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
> Report Id: 28b620b5-f3a0-40c3-99ae-962cab71bab8
> Faulting package full name:
> Please let me know if you need any more details.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DAEMON-457) Tomcat9.exe crash in windows server 2016 and 2019 while updating service.
[
https://issues.apache.org/jira/browse/DAEMON-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas updated DAEMON-457:
---
Description:
Tomcat9.exe crash in windows server 2016 and 2019 while updating service. We
have observer issue from Tomcat 9 version 9.0.70 and above. It was working fine
with Tomcat version 9.0.69.
Environment details:
OS: Windows server 2016 and 2019
Disk space: More than 80 GB
RAM: 8GB and more
VC Redist x64: 14.29.30139.0
Tomcat service details:
JvmMs=512
JvmMx=3076
After creating tomcat service, We run below command to update service with
JavaOption9
{code}
Tomcat9 //US//Tomcat9 ++JvmOptions9
--add-opens=java.base/java.lang.reflect=ALL-UNNAMED#--add-opens=java.base/jdk.internal.reflect=ALL-UNNAMED#--add-opens=java.base/java.lang.annotation=ALL-UNNAMED#--add-opens=java.base/java.util.Date=ALL-UNNAMED#--add-opens=java.base/java.io=ALL-UNNAMED#--add-opens=java.base/java.util=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED#--add-opens=java.base/java.math=ALL-UNNAMED#--add-opens=java.base/java.text=ALL-UNNAMED#--add-opens=java.base/javax.net.ssl=ALL-UNNAMED#--add-opens=java.base/java.time=ALL-UNNAMED
{code}
Above command fails with below crash in EventViewer:
Faulting application name: tomcat9.exe, version: 1.3.3.0, time stamp: 0x637e7ca5
Faulting module name: ntdll.dll, version: 10.0.17763.2237, time stamp:
0x65420ea4
Exception code: 0xc374
Fault offset: 0x000fa979
Faulting process id: 0x298
Faulting application start time: 0x01d967f65ac00dce
Faulting application path: C:\Program Files\DELL\WMS\Tomcat-9\bin\tomcat9.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 28b620b5-f3a0-40c3-99ae-962cab71bab8
Faulting package full name:
Please let me know if you need any more details.
was:
Tomcat9.exe crash in windows server 2016 and 2019 while updating service. We
have observer issue from Tomcat 9 version 9.0.70 and above. It was working fine
with Tomcat version 9.0.69.
Environment details:
OS: Windows server 2016 and 2019
Disk space: More than 80 GB
RAM: 8GB and more
VC Redist x64: 14.29.30139.0
Tomcat service details:
JvmMs=512
JvmMx=3076
After creating tomcat service, We run below command to update service with
JavaOption9
Tomcat9 //US//Tomcat9 ++JvmOptions9
--add-opens=java.base/java.lang.reflect=ALL-UNNAMED#--add-opens=java.base/jdk.internal.reflect=ALL-UNNAMED#--add-opens=java.base/java.lang.annotation=ALL-UNNAMED#--add-opens=java.base/java.util.Date=ALL-UNNAMED#--add-opens=java.base/java.io=ALL-UNNAMED#--add-opens=java.base/java.util=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED#--add-opens=java.base/java.math=ALL-UNNAMED#--add-opens=java.base/java.text=ALL-UNNAMED#--add-opens=java.base/javax.net.ssl=ALL-UNNAMED#--add-opens=java.base/java.time=ALL-UNNAMED
Above command fails with below crash in EventViewer:
Faulting application name: tomcat9.exe, version: 1.3.3.0, time stamp: 0x637e7ca5
Faulting module name: ntdll.dll, version: 10.0.17763.2237, time stamp:
0x65420ea4
Exception code: 0xc374
Fault offset: 0x000fa979
Faulting process id: 0x298
Faulting application start time: 0x01d967f65ac00dce
Faulting application path: C:\Program Files\DELL\WMS\Tomcat-9\bin\tomcat9.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 28b620b5-f3a0-40c3-99ae-962cab71bab8
Faulting package full name:
Please let me know if you need any more details.
> Tomcat9.exe crash in windows server 2016 and 2019 while updating service.
> -
>
> Key: DAEMON-457
> URL: https://issues.apache.org/jira/browse/DAEMON-457
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.3
> Environment: Windows Server 2016 and 2019
>Reporter: Denish Kothadiya
>Priority: Critical
> Attachments: logs.zip
>
>
> Tomcat9.exe crash in windows server 2016 and 2019 while updating service. We
> have observer issue from Tomcat 9 version 9.0.70 and above. It was working
> fine with Tomcat version 9.0.69.
> Environment details:
> OS: Windows server 2016 and 2019
> Disk space: More than 80 GB
> RAM: 8GB and more
> VC Redist x64: 14.29.30139.0
> Tomcat service details:
> JvmMs=512
> JvmMx=3076
> After creating tomcat service, We run below command to update service with
> JavaOption9
> {code}
> Tomcat9 //US//Tomcat9 ++JvmOptions9
>
[jira] [Resolved] (DAEMON-456) Prunsrv.exe delete service doesn't work from the batch script
[ https://issues.apache.org/jira/browse/DAEMON-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-456. Resolution: Works for Me The Tomcat service.bat script happily adds and deletes the service. This looks like a configuration (permissions?) issue. Please use the Commons users@ mailing list if you require further support. > Prunsrv.exe delete service doesn't work from the batch script > - > > Key: DAEMON-456 > URL: https://issues.apache.org/jira/browse/DAEMON-456 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.3 >Reporter: YICHUN ZHAO >Priority: Major > > I have been using prunsrv 1.0.15 on a Windows Server, and the delete service > command worked perfectly. However, after upgrading to version 1.3.3, the same > command has stopped functioning when executed from a script. > Although the delete command works as expected when run from an admin CMD > terminal, I checked the 1.3.3 documentation and found no changes in the > delete syntax. This makes me wonder if the issue stems from new security > checks added in version 1.3.3 or if there are other reasons for this problem. > I would appreciate any assistance or insights on this issue. Thanks in > advance! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DAEMON-452) Should we create the target folder before apxSecurityGrantFileAccessToUser?
[
https://issues.apache.org/jira/browse/DAEMON-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-452.
Fix Version/s: 1.3.4
Resolution: Fixed
> Should we create the target folder before apxSecurityGrantFileAccessToUser?
> ---
>
> Key: DAEMON-452
> URL: https://issues.apache.org/jira/browse/DAEMON-452
> Project: Commons Daemon
> Issue Type: Improvement
> Components: prunsrv
>Affects Versions: 1.3.3
> Environment: Windows
>Reporter: Gary D. Gregory
>Priority: Major
> Fix For: 1.3.4
>
>
> Our API apxSecurityGrantFileAccessToUser will fail if the target folder does
> not exist.
> Shouldn't we create this folder in advance of this call?
> Names and paths obfuscated in this example:
> {code}
> [2023-01-27 13:55:39] [info] ( prunsrv.c:2018) [ 7340] Apache Commons Daemon
> procrun (1.3.3.0 64-bit) started.
> [2023-01-27 13:55:39] [debug] ( prunsrv.c:774 ) [ 7340] Installing service...
> [2023-01-27 13:55:39] [info] ( prunsrv.c:831 ) [ 7340] Installing service
> 'ABC' name 'XYZ'.
> [2023-01-27 13:55:39] [debug] ( prunsrv.c:860 ) [ 7340] Setting service
> description 'XYZ'.
> [2023-01-27 13:55:39] [warn] ( prunsrv.c:759 ) [ 7340] Failed to grant
> service user 'NT AUTHORITY\LocalService' write permissions to log path
> 'C:\ProgramData\Example Company\Example Product\10.3991.0.0\Default\logs' due
> to error '2: The system cannot find the file specified.'
> [2023-01-27 13:55:39] [info] ( prunsrv.c:882 ) [ 7340] Service 'ABC'
> installed.
> [2023-01-27 13:55:39] [info] ( prunsrv.c:2102) [ 7340] Apache Commons Daemon
> procrun finished.
> Service 'XYZ' was installed succesfully
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-451) Prunsrv does not use configured stack size for the main thread in jvm mode
[
https://issues.apache.org/jira/browse/DAEMON-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-451.
Fix Version/s: 1.3.4
Resolution: Fixed
Thanks for the research and the patch.
> Prunsrv does not use configured stack size for the main thread in jvm mode
> --
>
> Key: DAEMON-451
> URL: https://issues.apache.org/jira/browse/DAEMON-451
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.3.3
>Reporter: Konstantin Kolinko
>Priority: Minor
> Fix For: 1.3.4
>
> Attachments:
> 0001-Fix-DAEMON-451.-Honor-the-stack-size-option-when-cre.patch
>
>
> This issue was originally reported for Apache Tomcat, see
> [https://bz.apache.org/bugzilla/show_bug.cgi?id=66327]
> A user provided a sample web application (see BZ 66327 attachment 38426).
> This web application was deployed on Apache Tomcat 9.0.70 (uses Commons
> Daemon 1.3.3), configured as a Windows Service.
> The sample application performs a deep recursion at startup, that prints
> numbers from 1 up to 25000. In the default configuration it fails with a
> StackOverflowError.
> To reproduce:
> 1. Build the sample web application:
> 1.1. Download it from BZ 66327 (attachment 38426).
> 1.2. Change its pom.xml file, removing "jersey-container-servlet" from
> dependencies. I do not know why it is there, it is not needed.
> 1.3. Build it with Apache Maven (`mvn package`). The result is
> target/TestStack-1.0-SNAPSHOT.war
> 2. Install Apache Tomcat 9 on Windows as a service:
> 2.1. Download and run the "32-bit/64-bit Windows Service Installer" (*.exe)
> from
> https://tomcat.apache.org/download-90.cgi
> 2.2. Run it. Use default options, but once installation finishes choose to do
> not start the service.
> 3. Deploy the web appplication on Tomcat:
> 3.1. Copy the war file into webapps directory of Tomcat.
> 4. Go into the bin directory of Tomcat and run prunmgr (tomcat9w.exe).
> 5. Start Tomcat service, from the first page of prunmgr dialog.
> 6. See the files in the logs directory of Tomcat.
> - See the localhost.2022-*{*}-{*}*.log file for a StackOverflowError
> - See the tomcat9-stdout.2022-{*}-{*}*.log file for recursion counter.
> If the web application starts successfully, there will be no
> StackOverflowError, and the counter will go up to 25000.
> If the web application fails to start, there will be a StackOverflowError,
> and the recursion counter will stop at some value, usually somewhere around
> 15000.
> 7. Try to increase the stack size:
> 7.1. Stop the service. Clear the files in the logs directory.
> 7.2. In prunmgr dialog (page "Java") change "Thread stack size" to a higher
> value, e.g. 3072.
> 7.3. Do not forget to press the "Apply" button.
> 7.4. Start the service.
> Expected behaviour:
> It is expected that changing the "Thread stack size" value to a higher value
> would eventually allow the web application to start successfully.
> Actual behaviour:
> It makes no difference.
> If I reconfigure Tomcat to use a thread pool when starting web applications,
> instead of using the main thread, the behaviour changes to the expected one.
> E.g. if you add startStopThreads="3" to a Host element in its conf/server.xml
> file. See Configuration Reference here:
> https://tomcat.apache.org/tomcat-9.0-doc/config/host.html
> Note: procrun here runs in jvm mode. The configuration for Tomcat is as
> follows (see bin/service.bat file):
> --StartMode jvm
> --StopMode jvm
> --StartClass org.apache.catalina.startup.Bootstrap
> --StopClass org.apache.catalina.startup.Bootstrap
> --StartParams start
> --StopParams stop
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DAEMON-457) Tomcat9.exe crash in windows server 2016 and 2019 while updating service.
[ https://issues.apache.org/jira/browse/DAEMON-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas updated DAEMON-457: --- Fix Version/s: (was: 1.3.3) > Tomcat9.exe crash in windows server 2016 and 2019 while updating service. > - > > Key: DAEMON-457 > URL: https://issues.apache.org/jira/browse/DAEMON-457 > Project: Commons Daemon > Issue Type: Bug >Affects Versions: 1.3.3 > Environment: Windows Server 2016 and 2019 >Reporter: Denish Kothadiya >Priority: Critical > Attachments: logs.zip > > > Tomcat9.exe crash in windows server 2016 and 2019 while updating service. We > have observer issue from Tomcat 9 version 9.0.70 and above. It was working > fine with Tomcat version 9.0.69. > Environment details: > OS: Windows server 2016 and 2019 > Disk space: More than 80 GB > RAM: 8GB and more > VC Redist x64: 14.29.30139.0 > Tomcat service details: > JvmMs=512 > JvmMx=3076 > After creating tomcat service, We run below command to update service with > JavaOption9 > Tomcat9 //US//Tomcat9 ++JvmOptions9 > --add-opens=java.base/java.lang.reflect=ALL-UNNAMED#--add-opens=java.base/jdk.internal.reflect=ALL-UNNAMED#--add-opens=java.base/java.lang.annotation=ALL-UNNAMED#--add-opens=java.base/java.util.Date=ALL-UNNAMED#--add-opens=java.base/java.io=ALL-UNNAMED#--add-opens=java.base/java.util=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent=ALL-UNNAMED#--add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED#--add-opens=java.base/java.math=ALL-UNNAMED#--add-opens=java.base/java.text=ALL-UNNAMED#--add-opens=java.base/javax.net.ssl=ALL-UNNAMED#--add-opens=java.base/java.time=ALL-UNNAMED > Above command fails with below crash in EventViewer: > Faulting application name: tomcat9.exe, version: 1.3.3.0, time stamp: > 0x637e7ca5 > Faulting module name: ntdll.dll, version: 10.0.17763.2237, time stamp: > 0x65420ea4 > Exception code: 0xc374 > Fault offset: 0x000fa979 > Faulting process id: 0x298 > Faulting application start time: 0x01d967f65ac00dce > Faulting application path: C:\Program Files\DELL\WMS\Tomcat-9\bin\tomcat9.exe > Faulting module path: C:\Windows\SYSTEM32\ntdll.dll > Report Id: 28b620b5-f3a0-40c3-99ae-962cab71bab8 > Faulting package full name: > Please let me know if you need any more details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DIGESTER-199) Noisy debug
[ https://issues.apache.org/jira/browse/DIGESTER-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17704539#comment-17704539 ] Mark Thomas commented on DIGESTER-199: -- Please provide a copy of the file that is being parsed. > Noisy debug > --- > > Key: DIGESTER-199 > URL: https://issues.apache.org/jira/browse/DIGESTER-199 > Project: Commons Digester > Issue Type: Bug >Affects Versions: 3.2 >Reporter: Delany >Priority: Major > > Large sections of a whitespace in the debug logs > [https://github.com/revelc/formatter-maven-plugin/issues/713] > https://issues.apache.org/jira/browse/MNG-7747 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DAEMON-454) Error 1084 in windows safe mode
[
https://issues.apache.org/jira/browse/DAEMON-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-454.
Resolution: Not A Problem
You'll need to configure your service to start in safe mode. See
[https://superuser.com/questions/1497924/how-to-disable-certain-services-from-running-in-safe-mode-but-run-in-normal-boot]
for an example of how to do this.
> Error 1084 in windows safe mode
> ---
>
> Key: DAEMON-454
> URL: https://issues.apache.org/jira/browse/DAEMON-454
> Project: Commons Daemon
> Issue Type: Bug
> Components: prunsrv
>Affects Versions: 1.3.3
> Environment: java 19.0.2
> prunsrv 1.3.3
> Windows 10 19043.928
>
>Reporter: Baris
>Priority: Major
> Attachments: 2023-03-08 15-32-14.mkv, Untitled.png,
> WinverUntitled.png, commons-daemon.2023-03-08.log, jnaReg.rar
>
>
> Hi , I was trying to run a windows service under safe mode of windows.
> Unfortunately I got 1084 error. I added my java project as jnaReg.rar . I
> tried commenting out this part in my code but no avail:
> ```
> // public static void registerHandler(){
> // Winsvc.SERVICE_STATUS_HANDLE service_status_handle =
> Advapi32.INSTANCE.RegisterServiceCtrlHandlerEx("hvldlpxpa", new
> Winsvc.HandlerEx() {
> // @Override
> // public int callback(int i, int i1, Pointer pointer, Pointer pointer1) {
> // System.out.println(i);
> // if(i == 1){
> // return 1;
> // }
> // return 120;
> // }
> // }, Pointer.NULL);
> // }
> ```
> Using java 19, prunsrv 1.3.3 .
> My typical register command is :
>
> prunsrv.exe //IS/Test --DisplayName=xpa --Description=h --Startup=manual
> --Jvm="pathToJvmDll"
> --Classpath=C:\Users\bunsal\IdeaProjects\jnaReg\target\JNA-jar-with-dependencies.jar
> --StartClass=Main --StopClass=Main --StartMode=jvm --StopMode=jvm
> --StopMethod=stopService --StartMethod=main --LogLevel=Debug
> --ServiceUser=LocalSystem
>
> (Looks like default service user is changed from localsystem to local service
> (compared to v1.1))
> Added commons-daemon log, and video of nothing being changed on windows event
> viewer.
> What should I do?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-455) Windows executable prunsrv.exe has an expired certificate
[ https://issues.apache.org/jira/browse/DAEMON-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-455. Resolution: Invalid The signatures are valid. The expiry date of the certificate does not affect the validity of the signature. Further the prunmgr.exe and prunsrv.exe binaries from 1.3.3 are signed with the exactly the same certificate. > Windows executable prunsrv.exe has an expired certificate > - > > Key: DAEMON-455 > URL: https://issues.apache.org/jira/browse/DAEMON-455 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.3 > Environment: Windows server >Reporter: Kristin Murphy >Priority: Major > Labels: certificate, prunsrv > Fix For: 1.3.4 > > Attachments: prunsrv-expired-certificate.png > > > The Windows executable file named prunsrv.exe has an expired certificate as > seen in the attached image. The certificate was valid from 1/13/2022 to > 1/14/2023. One thing I noticed is that the Windows executable file named > prunmgr.exe has a certificate that is valid from 9/30/2022 to 11/21/2033. If > possible it would be great to use the same certificate, or set the expiry of > the one in prunsrv.exe to be 10 years out as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DAEMON-445) Changes of DAEMON-441 cause trouble with empty env vars
[
https://issues.apache.org/jira/browse/DAEMON-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637922#comment-17637922
]
Mark Thomas commented on DAEMON-445:
Without an explanation of how to recreate the problem described here, this
issue will be resolved as WORKSFORME or similar.
> Changes of DAEMON-441 cause trouble with empty env vars
> ---
>
> Key: DAEMON-445
> URL: https://issues.apache.org/jira/browse/DAEMON-445
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Alexander Fischer
>Priority: Major
>
> The changes done via DAEMON-441, namely
> [https://github.com/apache/commons-daemon/commit/97b31058ecf5e4dc202188d8e8917f6caa90dcfc#diff-e7f9bbe0d9947378640c1e1c91d8dc72c93e6d1034218458158a1cc43f2f3b9fR278]
> lead to a failing service installation in case the environment variable
> exists but has no value.
> In my use case the supported environment variables are explicitly set empty
> if defaults shall be used. This is done to avoid interference with
> environment variables which may be set by the caling process.
> In such a case example output is:
> {noformat}
> [2022-06-29 11:32:11] [error] [10552] Error getting environment variable
> PR_LibraryPath
> [2022-06-29 11:32:11] [warn] [10552] Failed to grant service user '.\user'
> write permissions to log path 'C:\Windows\system32\LogFiles\Apache' due to
> error '19: The media is write protected.'
> {noformat}
> while the environment is set
> {noformat}
> PR_DESCRIPTION: tomcat-service description
> PR_DISPLAYNAME: tomcat-service
> PR_INSTALL: C:\apache-tomcat\bin\tomcat9.exe
> PR_SERVICEUSER: .\hidden
> PR_SERVICEPASSWORD: hidden
> PR_STARTUP: auto
> PR_CLASSPATH:
> C:\apache-tomcat/bin/bootstrap.jar;C:\apache-tomcat/bin/tomcat-juli.jar;
> PR_JAVA_HOME: C:\jdk
> PR_JVM: C:\jdk\bin\server\jvm.dll
> PR_JVMMS: 256
> PR_JVMMX: 3072
> PR_JVMOPTIONS:
> -Dcatalina.base=C:\tomcat-service;-Dcatalina.home=C:\apache-tomcat;-Djava.io.tmpdir=C:\tomcat-service/temp;
> PR_ENVIRONMENT:
> PATH='C:\Windows;C:\Windows\System32;C:\Windows\System32\Wbem;C:\apache-tomcat\bin'
> PR_LIBRARYPATH: C:\apache-tomcat/bin
> PR_STARTCLASS: org.apache.catalina.startup.Bootstrap
> PR_STARTMETHOD:
> PR_STARTPARAMS: start
> PR_STARTMODE: jvm
> PR_STARTPATH: C:\tomcat-service
> PR_STOPCLASS: org.apache.catalina.startup.Bootstrap
> PR_STOPMETHOD:
> PR_STOPPARAMS: stop
> PR_STOPMODE: jvm
> PR_STOPPATH: C:\tomcat-service
> PR_STOPTIMEOUT: 60
> PR_LOGJNIMESSAGES: 0
> PR_LOGLEVEL: Info
> PR_LOGPATH: C:\Logs\tomcat-service
> PR_LOGPREFIX: tomcat-service
> PR_STDERROR: auto
> PR_STDOUTPUT: auto
> PR_DEPENDSON: postgresql-x64-11;
> {noformat}
> Means, the environment variables PR_STOPMETHOD, PR_LIBRARYPATH and
> PR_STARTMETHOD are defined but empty.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-450) Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted unwanted two ACLs
[ https://issues.apache.org/jira/browse/DAEMON-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-450. Fix Version/s: 1.3.3 Resolution: Fixed Thanks for the proposed patch and the information on the leaks. > Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted unwanted > two ACLs > - > > Key: DAEMON-450 > URL: https://issues.apache.org/jira/browse/DAEMON-450 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.2 > Environment: Windows 7 SP1 x64 > Apache Tomcat 9.0.69 x86 (zip-dist) > >Reporter: Norimasa Yamamoto >Priority: Major > Fix For: 1.3.3 > > > Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted unwanted > two ACLs. > Repro at Tomcat9 directory on Admin Command Prompt (not Admin PowerShell). > > ren logs logs1 > > md logs > > icacls logs > logs NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M) > NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) > BUILTIN\Administrators:(I)(OI)(CI)(F) > BUILTIN\Users:(I)(OI)(CI)(M) > > bin\tomcat9.exe //US/Tomcat9 > > icacls logs > logs NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M) > NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) > BUILTIN\Administrators:(I)(OI)(CI)(F) > BUILTIN\Users:(I)(OI)(CI)(M) > > bin\tomcat9.exe //US/Tomcat9 > > icacls logs > logs NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M) > NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) > BUILTIN\Administrators:(I)(OI)(CI)(F) > BUILTIN\Users:(I)(OI)(CI)(M) > > for /l %i in (1,0,1) do bin\tomcat9.exe //US/Tomcat9 > : (...after 1000-2000 times...) > [2022-11-18 17:46:20] [warn] [ 2456] Failed to grant service user 'NT > AUTHORITY\LocalService' write permissions to log path > '\logs' due to error '1340: The inherited access > control list (ACL) or access control entry (ACE) could not be built.' > : > > icacls logs > logs NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\LOCAL SERVICE:(RX,W) > : > NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M) > NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) > BUILTIN\Administrators:(I)(OI)(CI)(F) > BUILTIN\Users:(I)(OI)(CI)(M) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DAEMON-450) Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted unwanted two ACLs
[ https://issues.apache.org/jira/browse/DAEMON-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17637393#comment-17637393 ] Mark Thomas commented on DAEMON-450: The original report was for Windows 7 which is no longer supported. This behaviour is not observed with a fully patched Windows 8.1 or fully patched Windows 10. I can repeat this with Windows Server 2012. I'll take a look at the proposed patch. > Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted unwanted > two ACLs > - > > Key: DAEMON-450 > URL: https://issues.apache.org/jira/browse/DAEMON-450 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.3.2 > Environment: Windows 7 SP1 x64 > Apache Tomcat 9.0.69 x86 (zip-dist) > >Reporter: Norimasa Yamamoto >Priority: Major > > Invoked "bin\tomcat9 //US/Tomcat9", logs directory will be inserted unwanted > two ACLs. > Repro at Tomcat9 directory on Admin Command Prompt (not Admin PowerShell). > > ren logs logs1 > > md logs > > icacls logs > logs NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M) > NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) > BUILTIN\Administrators:(I)(OI)(CI)(F) > BUILTIN\Users:(I)(OI)(CI)(M) > > bin\tomcat9.exe //US/Tomcat9 > > icacls logs > logs NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M) > NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) > BUILTIN\Administrators:(I)(OI)(CI)(F) > BUILTIN\Users:(I)(OI)(CI)(M) > > bin\tomcat9.exe //US/Tomcat9 > > icacls logs > logs NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M) > NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) > BUILTIN\Administrators:(I)(OI)(CI)(F) > BUILTIN\Users:(I)(OI)(CI)(M) > > for /l %i in (1,0,1) do bin\tomcat9.exe //US/Tomcat9 > : (...after 1000-2000 times...) > [2022-11-18 17:46:20] [warn] [ 2456] Failed to grant service user 'NT > AUTHORITY\LocalService' write permissions to log path > '\logs' due to error '1340: The inherited access > control list (ACL) or access control entry (ACE) could not be built.' > : > > icacls logs > logs NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\LOCAL SERVICE:(RX,W) > : > NT AUTHORITY\LOCAL SERVICE:(RX,W) > NT AUTHORITY\LOCAL SERVICE:(OI)(CI)(IO)(GR,GW,GE) > NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(M) > NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F) > BUILTIN\Administrators:(I)(OI)(CI)(F) > BUILTIN\Users:(I)(OI)(CI)(M) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DAEMON-449) Prunsrv fails to stop Open Liberty Windows service
[
https://issues.apache.org/jira/browse/DAEMON-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17634413#comment-17634413
]
Mark Thomas commented on DAEMON-449:
I think you are mis-reading the logs.
The line
[2022-11-14 15:04:19] [debug] ( prunsrv.c:1603) [ 6136] Waiting for worker to
finish...
shows that the service has started and the service wrapper is now waiting for
the service to end before that thread will continue.
I suspect what is happening is that server.bat is returning before the service
has fully started. Try adding some debug logging to show when server.bat exits.
> Prunsrv fails to stop Open Liberty Windows service
> --
>
> Key: DAEMON-449
> URL: https://issues.apache.org/jira/browse/DAEMON-449
> Project: Commons Daemon
> Issue Type: Bug
> Components: prunsrv
>Affects Versions: 1.2.2
> Environment: I don't think the Windows version matters, but I am
> using:
> Microsoft Windows [Version 10.0.19044.2006]
>Reporter: Jim Blye
>Priority: Major
> Attachments: commons-daemon.2022-09-28.log,
> commons-daemon.2022-09-28_afterKillingServer.log, server.bat
>
>
> When Prunsrv is used to register Open Liberty
> ([https://openliberty.io|https://openliberty.io/]) as a Windows Service,
> stopping the service hangs randomly.
> *To recreate the problem:*
> 1) Download open liberty ~300MB
>
> [https://public.dhe.ibm.com/ibmdl/export/pub/software/openliberty/runtime/release/22.0.0.10/openliberty-22.0.0.10.zip]
> Alternatively, you could use just the liberty kernel ~10MB
>
> [https://public.dhe.ibm.com/ibmdl/export/pub/software/openliberty/runtime/release/22.0.0.10/openliberty-kernel-22.0.0.10.zip]
> 2) md C:\temp\openliberty
> unzip openliberty-22.0.0.10.zip into C:\temp\openliberty
> 3) cd C:\temp\openliberty\wlp\bin
> 4) Run these two commands to make sure the server runs and to initialize
> the environment:
> server start
> server stop
> 5) Register liberty as a service (parameter is case sensitive). The
> following command is used to invoke prunsrv to register the service using the
> default name of defaultServer
> server registerWinService
> 6) Open the windows "services" app (services.msc). Start and stop the
> service until the stop hangs. It usually doesn't take more than a couple of
> tries.
>
> *Details*
> The *server.bat* script registers the service like this:
> "C:\temp\openliberty\wlp\bin\tools\win\prunsrv.exe" //IS//defaultServer
> --Startup=manual --DisplayName="defaultServer" --Description="Open Liberty"
> ++DependsOn=Tcpip
> --LogPath="C:\temp\openliberty\wlp\usr\servers\defaultServer\logs"
> --StdOutput=auto --StdError=auto --StartMode=exe
> --StartPath="C:\temp\openliberty\wlp"
> --StartImage="C:\temp\openliberty\wlp\bin\server.bat"
> ++StartParams=start#defaultServer --StopMode=exe
> --StopPath="C:\temp\openliberty\wlp" --StopImage="C:\temp\wlp\bin\server.bat"
> ++StopParams=stop#defaultServer --ServiceUser=LocalSystem
> After registering the service you can look at its properties. You will see:
> Path to executable:
> C:\temp\openliberty\wlp\bin\tools\win\prunsrv.exe //RS//defaultServer
> When I (and many of our customers) try to stop the service, it hangs. At
> that point, the server, named defaultServer is still up and running. I can
> send commands to the server. For instance, I can execute a "server dump"
> command. This sends the "dump" command to the server, and the server writes
> information to a file. I can also stop the server by executing "server
> stop". This sends the "stop" command to the server which causes the server
> to stop. When the server stops, the hanging Windows service stops as well.
> I have attached a *server.bat* which adds --LogLevel Debug to the prunsrv
> commands and also *commons-daemon.2022-09-28.log* which demonstrates the
> problem. It shows registering, starting, and stopping the service. Finally,
> I uploaded {*}commons-daemon.2022-09-28_afterKillingServer.log{*}, which is a
> continuation of the other log file which shows the result of issuing the
> server stop command to stop the server.
> Thanks for looking at this.
> Jim Blye
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DBCP-587) DBCP and Transparent Application Continuity
[ https://issues.apache.org/jira/browse/DBCP-587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17617090#comment-17617090 ] Mark Thomas commented on DBCP-587: -- `Oracle.jdbc.replay.OracleDataSourceImpl` is a `DataSource` not a `Driver`. You can't use it with `BasicDataSource`. I don't have an Oracle database to hand to test with but I'm fairly sure you need to configure a `PoolingDataSource` to use `Oracle.jdbc.replay.OracleDataSourceImpl`. That will require code changes. > DBCP and Transparent Application Continuity > --- > > Key: DBCP-587 > URL: https://issues.apache.org/jira/browse/DBCP-587 > Project: Commons DBCP > Issue Type: Bug >Affects Versions: 2.9.0 >Reporter: Kirk Hill >Priority: Major > > Oracle databases have a high-availability setup that uses an item called > Transparent Application Continuity. It requires using the following driver > class name for "oracle.jdbc.replay.OracleDataSourceImpl" When I attempt to > use this driver I get the following error message. > SQLException occurred : Cannot create JDBC driver of class > 'oracle.jdbc.replay.OracleDataSourceImpl' > Having this as a way to create connection pools would greatly enhance your > product. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (FILEUPLOAD-309) Release version 2.0.0
[ https://issues.apache.org/jira/browse/FILEUPLOAD-309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17616382#comment-17616382 ] Mark Thomas commented on FILEUPLOAD-309: Another option would be to run the current JAR through the Tomcat Migration Tool for Jakarta EE (other migration tools are available) and then publish the migrated JAR as 1.4.0-jakarta (or similar). > Release version 2.0.0 > - > > Key: FILEUPLOAD-309 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-309 > Project: Commons FileUpload > Issue Type: Wish >Reporter: Thiago Henrique Hupner >Priority: Major > > At Piranha, we've migrated to use the new Jakarta namespace. > One of our dependencies is the Commons File Upload, but the latest version > available is 1.4. > Looking around at the source code, I've found that the code is already > prepared for the new Jakarta namespace. > So, I want to know if there's a plan to release a new version soon. Or at > least a 2.0.0 milestone. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DAEMON-449) Prunsrv fails to stop Open Liberty Windows service
[
https://issues.apache.org/jira/browse/DAEMON-449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612763#comment-17612763
]
Mark Thomas commented on DAEMON-449:
You could try updating to the latest version but I doubt that will help.
Enabling debug logging, particularly with the latest version, might provide
some additional information.
If you can show that Daemon isn't calling stop then there would be a bug here
but the logs indicate that stop is being called and Open Liberty isn't
responding.
I suspect the issues is in Open Liberty rather than Commons Daemon. The
different exit code (20 vs 0) might be a clue.
> Prunsrv fails to stop Open Liberty Windows service
> --
>
> Key: DAEMON-449
> URL: https://issues.apache.org/jira/browse/DAEMON-449
> Project: Commons Daemon
> Issue Type: Bug
> Components: prunsrv
>Affects Versions: 1.2.2
> Environment: I don't think the Windows version matters, but I am
> using:
> Microsoft Windows [Version 10.0.19044.2006]
>Reporter: Jim Blye
>Priority: Major
> Attachments: commons-daemon.2022-09-28.log,
> commons-daemon.2022-09-28_afterKillingServer.log, server.bat
>
>
> When Prunsrv is used to register Open Liberty
> ([https://openliberty.io|https://openliberty.io/]) as a Windows Service,
> stopping the service hangs randomly.
> *To recreate the problem:*
> 1) Download open liberty ~300MB
>
> [https://public.dhe.ibm.com/ibmdl/export/pub/software/openliberty/runtime/release/22.0.0.10/openliberty-22.0.0.10.zip]
> Alternatively, you could use just the liberty kernel ~10MB
>
> [https://public.dhe.ibm.com/ibmdl/export/pub/software/openliberty/runtime/release/22.0.0.10/openliberty-kernel-22.0.0.10.zip]
> 2) md C:\temp\openliberty
> unzip openliberty-22.0.0.10.zip into C:\temp\openliberty
> 3) cd C:\temp\openliberty\wlp\bin
> 4) Run these two commands to make sure the server runs and to initialize
> the environment:
> server start
> server stop
> 5) Register liberty as a service (parameter is case sensitive). The
> following command is used to invoke prunsrv to register the service using the
> default name of defaultServer
> server registerWinService
> 6) Open the windows "services" app (services.msc). Start and stop the
> service until the stop hangs. It usually doesn't take more than a couple of
> tries.
>
> *Details*
> The *server.bat* script registers the service like this:
> "C:\temp\openliberty\wlp\bin\tools\win\prunsrv.exe" //IS//defaultServer
> --Startup=manual --DisplayName="defaultServer" --Description="Open Liberty"
> ++DependsOn=Tcpip
> --LogPath="C:\temp\openliberty\wlp\usr\servers\defaultServer\logs"
> --StdOutput=auto --StdError=auto --StartMode=exe
> --StartPath="C:\temp\openliberty\wlp"
> --StartImage="C:\temp\openliberty\wlp\bin\server.bat"
> ++StartParams=start#defaultServer --StopMode=exe
> --StopPath="C:\temp\openliberty\wlp" --StopImage="C:\temp\wlp\bin\server.bat"
> ++StopParams=stop#defaultServer --ServiceUser=LocalSystem
> After registering the service you can look at its properties. You will see:
> Path to executable:
> C:\temp\openliberty\wlp\bin\tools\win\prunsrv.exe //RS//defaultServer
> When I (and many of our customers) try to stop the service, it hangs. At
> that point, the server, named defaultServer is still up and running. I can
> send commands to the server. For instance, I can execute a "server dump"
> command. This sends the "dump" command to the server, and the server writes
> information to a file. I can also stop the server by executing "server
> stop". This sends the "stop" command to the server which causes the server
> to stop. When the server stops, the hanging Windows service stops as well.
> I have attached a *server.bat* which adds --LogLevel Debug to the prunsrv
> commands and also *commons-daemon.2022-09-28.log* which demonstrates the
> problem. It shows registering, starting, and stopping the service. Finally,
> I uploaded {*}commons-daemon.2022-09-28_afterKillingServer.log{*}, which is a
> continuation of the other log file which shows the result of issuing the
> server stop command to stop the server.
> Thanks for looking at this.
> Jim Blye
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-448) Service start fails with default Eclipse Temurin install
[
https://issues.apache.org/jira/browse/DAEMON-448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-448.
Fix Version/s: 1.3.2
Resolution: Fixed
Fixed. It was a NULL pointer de-reference when no JVM was configured.
> Service start fails with default Eclipse Temurin install
>
>
> Key: DAEMON-448
> URL: https://issues.apache.org/jira/browse/DAEMON-448
> Project: Commons Daemon
> Issue Type: Bug
> Components: prunsrv
>Affects Versions: 1.3.1
> Environment: * Windows 10 Pro 21H2 (OS Build 19044.1889) 64 bit
> * Eclipse Temurin Windows x64 JRE 11 (jdk-11.0.16.1+1) x64
> ** Screenshot from website, no direct link possible:
> ** !image-2022-09-16-14-53-28-807.png!
>Reporter: Glenn Matthys
>Priority: Major
> Fix For: 1.3.2
>
> Attachments: image-2022-09-16-14-49-32-981.png,
> image-2022-09-16-14-53-28-807.png, image-2022-09-16-15-02-53-131.png
>
>
> When installing Eclipse Temurin JRE version 11, notice _Set JAVA_HOME
> variable_ and _JavaSoft (Oracle) registry keys_ options are disabled in the
> default setup:
> !image-2022-09-16-14-49-32-981.png!
> prunsrv.exe successfully installs the service, but when trying to start it
> prunsrv.exe crashes:
> {{Faulting application name: xxx.exe, version: 1.3.1.0, time stamp:
> 0x6271349d}}
> {{Faulting module name: xxx.exe, version: 1.3.1.0, time stamp: 0x6271349d}}
> {{Exception code: 0xc005}}
> {{Fault offset: 0x7130}}
> {{Faulting process id: 0x1ddc}}
> {{Faulting application start time: 0x01d8c9ca012bfb46}}
> {{Faulting application path: C:\Program Files\xxx\xxx.exe}}
> {{Faulting module path: C:\Program Files\xxx\xxx.exe}}
> {{Report Id: a35b4a6a-63a3-4426-8061-495550439a97}}
> {{Faulting package full name: }}
> {{Faulting package-relative application ID: }}
> However when the default options are overridden and _Set JAVA_HOME variable_
> and _JavaSoft (Oracle) registry keys_ options are enabled:
> !image-2022-09-16-15-02-53-131.png!
> prunsrv.exe works correctly.
> Having prunsrv.exe work correctly or at least not die with an 0xc005
> (Access Denied) exception would improve user experience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DAEMON-448) Service start fails with default Eclipse Temurin install
[
https://issues.apache.org/jira/browse/DAEMON-448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612688#comment-17612688
]
Mark Thomas commented on DAEMON-448:
If JAVA_HOME isn't defined and there is no Java defined in the expected
registry locations then you are going to have to explicitly define the JVM you
want the service to use.
What we should be able to do is handle the situation better and fail to start
with a useful error message rather than crashing.
> Service start fails with default Eclipse Temurin install
>
>
> Key: DAEMON-448
> URL: https://issues.apache.org/jira/browse/DAEMON-448
> Project: Commons Daemon
> Issue Type: Bug
> Components: prunsrv
>Affects Versions: 1.3.1
> Environment: * Windows 10 Pro 21H2 (OS Build 19044.1889) 64 bit
> * Eclipse Temurin Windows x64 JRE 11 (jdk-11.0.16.1+1) x64
> ** Screenshot from website, no direct link possible:
> ** !image-2022-09-16-14-53-28-807.png!
>Reporter: Glenn Matthys
>Priority: Major
> Attachments: image-2022-09-16-14-49-32-981.png,
> image-2022-09-16-14-53-28-807.png, image-2022-09-16-15-02-53-131.png
>
>
> When installing Eclipse Temurin JRE version 11, notice _Set JAVA_HOME
> variable_ and _JavaSoft (Oracle) registry keys_ options are disabled in the
> default setup:
> !image-2022-09-16-14-49-32-981.png!
> prunsrv.exe successfully installs the service, but when trying to start it
> prunsrv.exe crashes:
> {{Faulting application name: xxx.exe, version: 1.3.1.0, time stamp:
> 0x6271349d}}
> {{Faulting module name: xxx.exe, version: 1.3.1.0, time stamp: 0x6271349d}}
> {{Exception code: 0xc005}}
> {{Fault offset: 0x7130}}
> {{Faulting process id: 0x1ddc}}
> {{Faulting application start time: 0x01d8c9ca012bfb46}}
> {{Faulting application path: C:\Program Files\xxx\xxx.exe}}
> {{Faulting module path: C:\Program Files\xxx\xxx.exe}}
> {{Report Id: a35b4a6a-63a3-4426-8061-495550439a97}}
> {{Faulting package full name: }}
> {{Faulting package-relative application ID: }}
> However when the default options are overridden and _Set JAVA_HOME variable_
> and _JavaSoft (Oracle) registry keys_ options are enabled:
> !image-2022-09-16-15-02-53-131.png!
> prunsrv.exe works correctly.
> Having prunsrv.exe work correctly or at least not die with an 0xc005
> (Access Denied) exception would improve user experience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (DAEMON-446) Update service (//US) does not change DependsOn
[ https://issues.apache.org/jira/browse/DAEMON-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-446. Fix Version/s: 1.3.2 Resolution: Fixed Thanks for the report. That looks like an oversight to me. Now fixed. > Update service (//US) does not change DependsOn > --- > > Key: DAEMON-446 > URL: https://issues.apache.org/jira/browse/DAEMON-446 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.2.2 > Environment: Windows 10, Windows Server several versions >Reporter: Pavel Rund >Priority: Major > Fix For: 1.3.2 > > > When installing a service, I can set dependency on other services using the > --DependsOn parameter. But when a try to add this dependency using //US > directive, nothing happens. > I know we don't use the latest version of procrun but I checked source codes > and if I don't misread it, the //US directive still does not chage DependsOn > parameter of the service. > Is that a purspose? If not, can this be repaired? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DAEMON-445) Changes of DAEMON-441 cause trouble with empty env vars
[
https://issues.apache.org/jira/browse/DAEMON-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612610#comment-17612610
]
Mark Thomas commented on DAEMON-445:
How are you setting an empty environment variable in Windows. Generally, trying
to do that deletes the environment variable.
> Changes of DAEMON-441 cause trouble with empty env vars
> ---
>
> Key: DAEMON-445
> URL: https://issues.apache.org/jira/browse/DAEMON-445
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.1
>Reporter: Alexander Fischer
>Priority: Major
>
> The changes done via DAEMON-441, namely
> [https://github.com/apache/commons-daemon/commit/97b31058ecf5e4dc202188d8e8917f6caa90dcfc#diff-e7f9bbe0d9947378640c1e1c91d8dc72c93e6d1034218458158a1cc43f2f3b9fR278]
> lead to a failing service installation in case the environment variable
> exists but has no value.
> In my use case the supported environment variables are explicitly set empty
> if defaults shall be used. This is done to avoid interference with
> environment variables which may be set by the caling process.
> In such a case example output is:
> {noformat}
> [2022-06-29 11:32:11] [error] [10552] Error getting environment variable
> PR_LibraryPath
> [2022-06-29 11:32:11] [warn] [10552] Failed to grant service user '.\user'
> write permissions to log path 'C:\Windows\system32\LogFiles\Apache' due to
> error '19: The media is write protected.'
> {noformat}
> while the environment is set
> {noformat}
> PR_DESCRIPTION: tomcat-service description
> PR_DISPLAYNAME: tomcat-service
> PR_INSTALL: C:\apache-tomcat\bin\tomcat9.exe
> PR_SERVICEUSER: .\hidden
> PR_SERVICEPASSWORD: hidden
> PR_STARTUP: auto
> PR_CLASSPATH:
> C:\apache-tomcat/bin/bootstrap.jar;C:\apache-tomcat/bin/tomcat-juli.jar;
> PR_JAVA_HOME: C:\jdk
> PR_JVM: C:\jdk\bin\server\jvm.dll
> PR_JVMMS: 256
> PR_JVMMX: 3072
> PR_JVMOPTIONS:
> -Dcatalina.base=C:\tomcat-service;-Dcatalina.home=C:\apache-tomcat;-Djava.io.tmpdir=C:\tomcat-service/temp;
> PR_ENVIRONMENT:
> PATH='C:\Windows;C:\Windows\System32;C:\Windows\System32\Wbem;C:\apache-tomcat\bin'
> PR_LIBRARYPATH: C:\apache-tomcat/bin
> PR_STARTCLASS: org.apache.catalina.startup.Bootstrap
> PR_STARTMETHOD:
> PR_STARTPARAMS: start
> PR_STARTMODE: jvm
> PR_STARTPATH: C:\tomcat-service
> PR_STOPCLASS: org.apache.catalina.startup.Bootstrap
> PR_STOPMETHOD:
> PR_STOPPARAMS: stop
> PR_STOPMODE: jvm
> PR_STOPPATH: C:\tomcat-service
> PR_STOPTIMEOUT: 60
> PR_LOGJNIMESSAGES: 0
> PR_LOGLEVEL: Info
> PR_LOGPATH: C:\Logs\tomcat-service
> PR_LOGPREFIX: tomcat-service
> PR_STDERROR: auto
> PR_STDOUTPUT: auto
> PR_DEPENDSON: postgresql-x64-11;
> {noformat}
> Means, the environment variables PR_STOPMETHOD, PR_LIBRARYPATH and
> PR_STARTMETHOD are defined but empty.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (DAEMON-435) While stopping service, service crashed with error 1067
[ https://issues.apache.org/jira/browse/DAEMON-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas closed DAEMON-435. -- Resolution: Cannot Reproduce No further information provided by OP. > While stopping service, service crashed with error 1067 > --- > > Key: DAEMON-435 > URL: https://issues.apache.org/jira/browse/DAEMON-435 > Project: Commons Daemon > Issue Type: Bug >Affects Versions: 1.2.4 >Reporter: Kaviarasi >Priority: Blocker > > When stopping the service, service crashes with Error 1067: The process > terminated unexpectedly. > > When enabled the debug mode for prunsrv, following messages are seen > > [2021-10-29 12:34:53] [debug] ( prunsrv.c:1892) [ 1816] Apache Commons Daemon > procrun log initialized. > [2021-10-29 12:34:53] [info] ( prunsrv.c:1896) [ 1816] Apache Commons Daemon > procrun (1.2.4.0 64-bit) started. > [2021-10-29 12:34:53] [info] ( prunsrv.c:945 ) [ 1816] Updating service... > [2021-10-29 12:34:53] [warn] ( service.c:143 ) [ 1816] Failed to obtain > service description > [2021-10-29 12:34:53] [info] ( prunsrv.c:1007) [ 1816] Updated service > 'OracleAVAgent'. > [2021-10-29 12:34:53] [info] ( prunsrv.c:1014) [ 1816] Finished updating > service 'OracleAVAgent'. > [2021-10-29 12:34:53] [info] ( prunsrv.c:1980) [ 1816] Apache Commons Daemon > procrun finished. > [2021-10-29 12:34:53] [debug] ( prunsrv.c:1032) [12208] reportServiceStatusE: > dwCurrentState = 4, dwWin32ExitCode = 0, dwWaitHint = 0, > dwServiceSpecificExitCode = 0. > [2021-10-29 12:34:53] [debug] ( prunsrv.c:1032) [12208] reportServiceStatusE: > dwCurrentState = 3, dwWin32ExitCode = 0, dwWaitHint = 3000, > dwServiceSpecificExitCode = 0. > [2021-10-29 12:34:53] [info] ( prunsrv.c:1132) [10076] Stopping service... > [2021-10-29 12:34:53] [debug] ( javajni.c:414 ) [10076] Loaded JVM DLL '', > home ''. > [2021-10-29 12:34:53] [debug] ( javajni.c:419 ) [10076] > JNI_GetCreatedJavaVMs... > [2021-10-29 12:34:53] [debug] ( javajni.c:1039) [ 8808] DLL search path set > to ' > [2021-10-29 12:34:53] [debug] ( javajni.c:1003) [ 8808] argv[0] = STOP > [2021-10-29 12:34:53] [debug] ( javajni.c:1003) [ 8808] argv[1] = -l > [2021-10-29 12:34:53] [debug] ( javajni.c:1003) [ 8808] argv[2] = WARNING > [2021-10-29 12:34:53] [debug] ( javajni.c:1062) [ 8808] Java worker thread > started for oracle/av/platform/agent/AgentController:main > [2021-10-29 12:34:53] [debug] ( javajni.c:1068) [ 8808] JNI calling static > void method oracle/av/platform/agent/AgentController:main > [2021-10-29 12:34:54] [debug] ( javajni.c:566 ) [12220] Exit hook with exit > code 0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (DAEMON-447) Allow to rotate stdout and stderr redirected logs
[
https://issues.apache.org/jira/browse/DAEMON-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17612594#comment-17612594
]
Mark Thomas commented on DAEMON-447:
Please provide your proposed change as a patch attached to this issue or as a
PR via GitHub.
> Allow to rotate stdout and stderr redirected logs
> --
>
> Key: DAEMON-447
> URL: https://issues.apache.org/jira/browse/DAEMON-447
> Project: Commons Daemon
> Issue Type: Improvement
> Components: prunsrv
>Affects Versions: 1.3.0, 1.3.1
> Environment: Windows 10; WIndows Server 2016
>Reporter: Ivan Pedruzzi
>Priority: Major
>
> We have a large legacy web application which makes use of System.out.println
> to print errors.
> Our Tomcat 9 is configured to redirect stdout to file using switch --StdOut
> In some peculiar conditions our web application can print a very large amount
> error which end up in the log file and can quickly fill the hard drive,
> crashing the system.
> Looking at the code in prunsrv.c it is possible to implement a simple
> rotation policy which would limit the size of the log from stdout to a
> configurable number of bytes.
> Piggy backing on the worker thread "eventThread", when the log file size is
> above a configurable threshold (new option StdOutFileMaxSize) we could make
> a copy of the log and truncate the file.
> To enable the rotation for the redirects, we would need 2 options:
> --Rotate
> --StdOutFileMaxSize
> These could be used for both stderr and stdout or split in dedicated options
>
> Here is the worked altered with my change. In my local tests it behaves as I
> expect.
> DWORD WINAPI eventThread(LPVOID lpParam)
> {
> DWORD dwRotateCnt = SO_LOGROTATE;
> for (;;) {
> DWORD dw = WaitForSingleObject(gSignalEvent, 1000);
> if (dw == WAIT_TIMEOUT) {
> /* Do process maintenance */
> if (SO_LOGROTATE != 0 && --dwRotateCnt == 0) {
> /* Perform log rotation. */
>
> /* START CHANGE */
>
> __int64 MAX_Mbytes = SO_STDOUTFILEMAXSIZE;
> struct _stat64 fileInfo;
> if (gStdwrap.szStdOutFilename
> && gStdwrap.fpStdOutFile
> && _fstat64(_fileno(gStdwrap.fpStdOutFile), ) == > 0
> && fileInfo.st_size > MAX_Mbytes) {
> WCHAR sPath[SIZ_PATHLEN];
> lstrlcpyW(sPath, MAX_PATH, gStdwrap.szStdOutFilename);
> lstrlcatW(sPath, SIZ_PATHMAX, L"-backup.log");
> //Make a copy of current log before truncating it
> CopyFileW(gStdwrap.szStdOutFilename, sPath, FALSE);
> //close current handle
> fclose(gStdwrap.fpStdOutFile);
> //re-open file to truncate it
> FILE* tempHandle = _wfsopen(gStdwrap.szStdOutFilename,
> L"w", _SH_DENYNO);
> fclose(tempHandle);
>
> //re-open in append mode
> gStdwrap.fpStdOutFile =
> _wfsopen(gStdwrap.szStdOutFilename, L"a", _SH_DENYNO);
> _dup2(_fileno(gStdwrap.fpStdOutFile), 1);
> *stdout = *(gStdwrap.fpStdOutFile);
> }
> /* END CHANGE */
> dwRotateCnt = SO_LOGROTATE;
> }
> continue;
> }
> if (dw == WAIT_OBJECT_0 && gSignalValid) {
> if (!GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT, 0)) {
> /* Invoke Thread dump */
> if (gWorker && _jni_startup)
> apxJavaDumpAllStacks(gWorker);
> }
> ResetEvent(gSignalEvent);
> continue;
> }
> break;
> }
> ExitThread(0);
> return 0;
> UNREFERENCED_PARAMETER(lpParam);
> }
>
>
>
>
>
>
>
>
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (BCEL-364) Integrating bcel into oss-fuzz
[ https://issues.apache.org/jira/browse/BCEL-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17607264#comment-17607264 ] Mark Thomas commented on BCEL-364: -- The "no false positives" claim does not stand up to scrutiny. The false positive rate for the Tomcat integration provided by Code Intelligence is currently running at between 80% and 90%. While a few bugs have been found, none of them have had any security implications. Based on the experience with Tomcat, and given that BCEL is neither designed nor intended to handle untrusted input, I'd question whether it is an effect use of the limited volunteer effort in the BCEL community to engage with this initiative without some changes. I strongly recommend that we make it a condition of engaging with this initiative that all reported issues are first manually vetted by Code Intelligence for validity BEFORE being passed to the BCEL project for resolution. > Integrating bcel into oss-fuzz > -- > > Key: BCEL-364 > URL: https://issues.apache.org/jira/browse/BCEL-364 > Project: Commons BCEL > Issue Type: Improvement >Reporter: A. Schaich >Priority: Minor > > Hi all, > we have prepared the [Initial > integration|https://github.com/CodeIntelligenceTesting/oss-fuzz/commit/8e98d61d59164683ff72203b5aa6768cb3d68acb] > of bcel into [Google OSS-Fuzz|https://github.com/google/oss-fuzz] which will > provide more security for your project. > > *Why do you need Fuzzing?* > The Code Intelligence JVM fuzzer > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer] has already found > [hundreds of bugs|https://github.com/CodeIntelligenceTesting/jazzer#findings] > in open source projects including for example > [OpenJDK|https://nvd.nist.gov/vuln/detail/CVE-2022-21360], > [Protobuf|https://nvd.nist.gov/vuln/detail/CVE-2021-22569] or > [jsoup|https://github.com/jhy/jsoup/security/advisories/GHSA-m72m-mhq2-9p6c]. > Fuzzing proved to be very effective having no false positives. It provides a > crashing input which helps you to reproduce and debug any finding easily. The > integration of your project into the OSS-Fuzz platform will enable continuous > fuzzing of your project by > [Jazzer|https://github.com/CodeIntelligenceTesting/jazzer]. > > *What do you need to do?* > The integration requires the maintainer or one established project commiter > to deal with the bug reports. > You need to create or provide one email address that is associated with a > google account as per > [here|https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/]. > When a bug is found, you will receive an email that will provide you with > access to ClusterFuzz, crash reports, code coverage reports and fuzzer > statistics. More than 1 person can be included. > > *How Code Intelligence can support?* > We will continue to add more fuzz targets to improve code coverage over time. > Furthermore, we are permanently enhancing fuzzing technologies by developing > new fuzzers and more bug detectors. > > Please let me know if you have any questions regarding fuzzing or the > OSS-Fuzz integration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (DAEMON-441) When installing a Windows service using Commons Daemon 1.3.0 the errorlevel is -1073741819
[
https://issues.apache.org/jira/browse/DAEMON-441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-441.
Fix Version/s: 1.3.1
Resolution: Fixed
> When installing a Windows service using Commons Daemon 1.3.0 the errorlevel
> is -1073741819
> --
>
> Key: DAEMON-441
> URL: https://issues.apache.org/jira/browse/DAEMON-441
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.0
> Environment: Windows 2016 Datacenter
>Reporter: Brian Andle
>Priority: Major
> Fix For: 1.3.1
>
> Attachments: Command_Prompt.png
>
>
> When attempting to use prunsrv.exe on Windows 2016 to create a service a
> Windows Event error is logged and the errorlevel is returned as -1073741819
> Running the following command:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=My Service
> --DisplayName=My Service {code}
> Results in the following Windows Event Log entry
>
> {code:java}
> Faulting application name: prunsrv.exe, version: 1.3.0.0, time stamp:
> 0x622b3ac0
> Faulting module name: prunsrv.exe, version: 1.3.0.0, time stamp: 0x622b3ac0
> Exception code: 0xc005
> Fault offset: 0x6e70
> Faulting process id: 0x1d88
> Faulting application start time: 0x01d845f90eb4351a
> Faulting application path: C:\myfolder\prunsrv.exe
> Faulting module path: C:\myfolder\prunsrv.exe
> Report Id: 409b7098-42bd-4036-aa61-b19eecdb1bd7
> Faulting package full name:
> Faulting package-relative application ID: {code}
> Doing an echo %errorlevel% shows -1073741819 instead of the expected 0
> Version 1.2.4.0 works correctly on both Windows 10 and 2016
> *NOTE:* The service does appear to actually install on 2016, however most
> deploy scripts will expect an error level of 0 and will fail if a non 0 value
> it returned.
> h3. Workaround
> Define a *--LogPath* value and do not use the default
> %SystemRoot%\System32\LogFiles\Apache path
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (DAEMON-441) When installing a Windows service using Commons Daemon 1.3.0 the errorlevel is -1073741819
[
https://issues.apache.org/jira/browse/DAEMON-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530093#comment-17530093
]
Mark Thomas commented on DAEMON-441:
I've updated the error message to show the path.
> When installing a Windows service using Commons Daemon 1.3.0 the errorlevel
> is -1073741819
> --
>
> Key: DAEMON-441
> URL: https://issues.apache.org/jira/browse/DAEMON-441
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.0
> Environment: Windows 2016 Datacenter
>Reporter: Brian Andle
>Priority: Major
> Attachments: Command_Prompt.png
>
>
> When attempting to use prunsrv.exe on Windows 2016 to create a service a
> Windows Event error is logged and the errorlevel is returned as -1073741819
> Running the following command:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=My Service
> --DisplayName=My Service {code}
> Results in the following Windows Event Log entry
>
> {code:java}
> Faulting application name: prunsrv.exe, version: 1.3.0.0, time stamp:
> 0x622b3ac0
> Faulting module name: prunsrv.exe, version: 1.3.0.0, time stamp: 0x622b3ac0
> Exception code: 0xc005
> Fault offset: 0x6e70
> Faulting process id: 0x1d88
> Faulting application start time: 0x01d845f90eb4351a
> Faulting application path: C:\myfolder\prunsrv.exe
> Faulting module path: C:\myfolder\prunsrv.exe
> Report Id: 409b7098-42bd-4036-aa61-b19eecdb1bd7
> Faulting package full name:
> Faulting package-relative application ID: {code}
> Doing an echo %errorlevel% shows -1073741819 instead of the expected 0
> Version 1.2.4.0 works correctly on both Windows 10 and 2016
> *NOTE:* The service does appear to actually install on 2016, however most
> deploy scripts will expect an error level of 0 and will fail if a non 0 value
> it returned.
> h3. Workaround
> Define a *--LogPath* value and do not use the default
> %SystemRoot%\System32\LogFiles\Apache path
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (DAEMON-441) When installing a Windows service using Commons Daemon 1.3.0 the errorlevel is -1073741819
[
https://issues.apache.org/jira/browse/DAEMON-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529360#comment-17529360
]
Mark Thomas commented on DAEMON-441:
Thanks for those tests. That is what I expected to see which is good.
1.3.0 made some changes to stdout and stderr redirection. This was a fix for
DAEMON-437. The issue was that the output files could be used both by a running
service and by the separate process that starts / stops / updates the running
service. Multiple processes trying to write to the same file is generally a
cause of problems. The solution chosen was to only redirect stdout and stderr
for a running service. Hence why you see log messages on the console rather
than a redirected file being created.
There was some discussion of alternative approaches in DAEMON-437.
I'm still thinking about reporting the actual log path rather than
when no explicit path is set. I'd be interested in your views on that.
> When installing a Windows service using Commons Daemon 1.3.0 the errorlevel
> is -1073741819
> --
>
> Key: DAEMON-441
> URL: https://issues.apache.org/jira/browse/DAEMON-441
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.0
> Environment: Windows 2016 Datacenter
>Reporter: Brian Andle
>Priority: Major
> Attachments: Command_Prompt.png
>
>
> When attempting to use prunsrv.exe on Windows 2016 to create a service a
> Windows Event error is logged and the errorlevel is returned as -1073741819
> Running the following command:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=My Service
> --DisplayName=My Service {code}
> Results in the following Windows Event Log entry
>
> {code:java}
> Faulting application name: prunsrv.exe, version: 1.3.0.0, time stamp:
> 0x622b3ac0
> Faulting module name: prunsrv.exe, version: 1.3.0.0, time stamp: 0x622b3ac0
> Exception code: 0xc005
> Fault offset: 0x6e70
> Faulting process id: 0x1d88
> Faulting application start time: 0x01d845f90eb4351a
> Faulting application path: C:\myfolder\prunsrv.exe
> Faulting module path: C:\myfolder\prunsrv.exe
> Report Id: 409b7098-42bd-4036-aa61-b19eecdb1bd7
> Faulting package full name:
> Faulting package-relative application ID: {code}
> Doing an echo %errorlevel% shows -1073741819 instead of the expected 0
> Version 1.2.4.0 works correctly on both Windows 10 and 2016
> *NOTE:* The service does appear to actually install on 2016, however most
> deploy scripts will expect an error level of 0 and will fail if a non 0 value
> it returned.
> h3. Workaround
> Define a *--LogPath* value and do not use the default
> %SystemRoot%\System32\LogFiles\Apache path
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (DAEMON-435) While stopping service, service crashed with error 1067
[ https://issues.apache.org/jira/browse/DAEMON-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528764#comment-17528764 ] Mark Thomas commented on DAEMON-435: Without steps to reproduce this failure, this issue will eventually get resolved as unable to reproduce. > While stopping service, service crashed with error 1067 > --- > > Key: DAEMON-435 > URL: https://issues.apache.org/jira/browse/DAEMON-435 > Project: Commons Daemon > Issue Type: Bug >Affects Versions: 1.2.4 >Reporter: Kaviarasi >Priority: Blocker > > When stopping the service, service crashes with Error 1067: The process > terminated unexpectedly. > > When enabled the debug mode for prunsrv, following messages are seen > > [2021-10-29 12:34:53] [debug] ( prunsrv.c:1892) [ 1816] Apache Commons Daemon > procrun log initialized. > [2021-10-29 12:34:53] [info] ( prunsrv.c:1896) [ 1816] Apache Commons Daemon > procrun (1.2.4.0 64-bit) started. > [2021-10-29 12:34:53] [info] ( prunsrv.c:945 ) [ 1816] Updating service... > [2021-10-29 12:34:53] [warn] ( service.c:143 ) [ 1816] Failed to obtain > service description > [2021-10-29 12:34:53] [info] ( prunsrv.c:1007) [ 1816] Updated service > 'OracleAVAgent'. > [2021-10-29 12:34:53] [info] ( prunsrv.c:1014) [ 1816] Finished updating > service 'OracleAVAgent'. > [2021-10-29 12:34:53] [info] ( prunsrv.c:1980) [ 1816] Apache Commons Daemon > procrun finished. > [2021-10-29 12:34:53] [debug] ( prunsrv.c:1032) [12208] reportServiceStatusE: > dwCurrentState = 4, dwWin32ExitCode = 0, dwWaitHint = 0, > dwServiceSpecificExitCode = 0. > [2021-10-29 12:34:53] [debug] ( prunsrv.c:1032) [12208] reportServiceStatusE: > dwCurrentState = 3, dwWin32ExitCode = 0, dwWaitHint = 3000, > dwServiceSpecificExitCode = 0. > [2021-10-29 12:34:53] [info] ( prunsrv.c:1132) [10076] Stopping service... > [2021-10-29 12:34:53] [debug] ( javajni.c:414 ) [10076] Loaded JVM DLL '', > home ''. > [2021-10-29 12:34:53] [debug] ( javajni.c:419 ) [10076] > JNI_GetCreatedJavaVMs... > [2021-10-29 12:34:53] [debug] ( javajni.c:1039) [ 8808] DLL search path set > to ' > [2021-10-29 12:34:53] [debug] ( javajni.c:1003) [ 8808] argv[0] = STOP > [2021-10-29 12:34:53] [debug] ( javajni.c:1003) [ 8808] argv[1] = -l > [2021-10-29 12:34:53] [debug] ( javajni.c:1003) [ 8808] argv[2] = WARNING > [2021-10-29 12:34:53] [debug] ( javajni.c:1062) [ 8808] Java worker thread > started for oracle/av/platform/agent/AgentController:main > [2021-10-29 12:34:53] [debug] ( javajni.c:1068) [ 8808] JNI calling static > void method oracle/av/platform/agent/AgentController:main > [2021-10-29 12:34:54] [debug] ( javajni.c:566 ) [12220] Exit hook with exit > code 0 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (DAEMON-442) ProcRun classpath limitation of 1010 characters truncates the classpath string for many libraries on the classpath
[ https://issues.apache.org/jira/browse/DAEMON-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-442. Fix Version/s: 1.3.1 Resolution: Fixed The size limit on the message component of the log entry has been increased from 1024 characters to 4096. > ProcRun classpath limitation of 1010 characters truncates the classpath > string for many libraries on the classpath > -- > > Key: DAEMON-442 > URL: https://issues.apache.org/jira/browse/DAEMON-442 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.2.3 >Reporter: Japie vd Linde >Priority: Minor > Fix For: 1.3.1 > > Attachments: Service-Service-Log.2022-04-06.log > > > When installing a service and it has a long java class path, it truncates of > the remainder of the class path which seems to have a 1010 character limit > when specifying a big amount of jars. > > See here where the JVM option shows the classpath being truncated: > [2022-04-06 16:31:57] [debug] ( javajni.c:817 ) [ 3228] JVM Option[2] > -Djava.class.path=C:\\Postilion\\eSocket.POS\\java;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-configuration-1.10.jar;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-lang-2.6.jar;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-logging-1.2.jar;C:\\Postilion\\eSocket.POS\\bin\\bcpkix-jdk15.jar;C:\\Postilion\\eSocket.POS\\bin\\bcprov-jdk15.jar;C:\\Postilion\\eSocket.POS\\bin\\comm.jar;C:\\Postilion\\eSocket.POS\\bin\\esocket-tools-log4j.jar;C:\\Postilion\\eSocket.POS\\bin\\esocket-tools.jar;C:\\Postilion\\eSocket.POS\\bin\\hsqldb-2.3.4.jar;C:\\Postilion\\eSocket.POS\\bin\\log4j-api-2.13.3.jar;C:\\Postilion\\eSocket.POS\\bin\\log4j-core-2.13.3.jar;C:\\Postilion\\eSocket.POS\\bin\\mssql-jdbc-8.2.2.jre8.jar;C:\\Postilion\\eSocket.POS\\bin\\postespos-sdk.jar;C:\\Postilion\\eSocket.POS\\bin\\commons-daemon.jar;C:\\Postilion\\eSocket.POS\\bin\\endorsed\\xercesImpl.jar;C:\\Postilion\\eSocket.POS\\bin\\endorsed\\xml-apis.jar;C:\\Postilion\\eSocket.POS\\bin\\jai_codec.jar;C:\\Postilion\\eSocket.POS\\bin\\j > See the service log attached. > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (DAEMON-442) ProcRun classpath limitation of 1010 characters truncates the classpath string for many libraries on the classpath
[ https://issues.apache.org/jira/browse/DAEMON-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528755#comment-17528755 ] Mark Thomas commented on DAEMON-442: This has nothing to do with Windows path name limits. > ProcRun classpath limitation of 1010 characters truncates the classpath > string for many libraries on the classpath > -- > > Key: DAEMON-442 > URL: https://issues.apache.org/jira/browse/DAEMON-442 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.2.3 >Reporter: Japie vd Linde >Priority: Minor > Attachments: Service-Service-Log.2022-04-06.log > > > When installing a service and it has a long java class path, it truncates of > the remainder of the class path which seems to have a 1010 character limit > when specifying a big amount of jars. > > See here where the JVM option shows the classpath being truncated: > [2022-04-06 16:31:57] [debug] ( javajni.c:817 ) [ 3228] JVM Option[2] > -Djava.class.path=C:\\Postilion\\eSocket.POS\\java;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-configuration-1.10.jar;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-lang-2.6.jar;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-logging-1.2.jar;C:\\Postilion\\eSocket.POS\\bin\\bcpkix-jdk15.jar;C:\\Postilion\\eSocket.POS\\bin\\bcprov-jdk15.jar;C:\\Postilion\\eSocket.POS\\bin\\comm.jar;C:\\Postilion\\eSocket.POS\\bin\\esocket-tools-log4j.jar;C:\\Postilion\\eSocket.POS\\bin\\esocket-tools.jar;C:\\Postilion\\eSocket.POS\\bin\\hsqldb-2.3.4.jar;C:\\Postilion\\eSocket.POS\\bin\\log4j-api-2.13.3.jar;C:\\Postilion\\eSocket.POS\\bin\\log4j-core-2.13.3.jar;C:\\Postilion\\eSocket.POS\\bin\\mssql-jdbc-8.2.2.jre8.jar;C:\\Postilion\\eSocket.POS\\bin\\postespos-sdk.jar;C:\\Postilion\\eSocket.POS\\bin\\commons-daemon.jar;C:\\Postilion\\eSocket.POS\\bin\\endorsed\\xercesImpl.jar;C:\\Postilion\\eSocket.POS\\bin\\endorsed\\xml-apis.jar;C:\\Postilion\\eSocket.POS\\bin\\jai_codec.jar;C:\\Postilion\\eSocket.POS\\bin\\j > See the service log attached. > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (DAEMON-442) ProcRun classpath limitation of 1010 characters truncates the classpath string for many libraries on the classpath
[ https://issues.apache.org/jira/browse/DAEMON-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas updated DAEMON-442: --- Priority: Minor (was: Major) > ProcRun classpath limitation of 1010 characters truncates the classpath > string for many libraries on the classpath > -- > > Key: DAEMON-442 > URL: https://issues.apache.org/jira/browse/DAEMON-442 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.2.3 >Reporter: Japie vd Linde >Priority: Minor > Attachments: Service-Service-Log.2022-04-06.log > > > When installing a service and it has a long java class path, it truncates of > the remainder of the class path which seems to have a 1010 character limit > when specifying a big amount of jars. > > See here where the JVM option shows the classpath being truncated: > [2022-04-06 16:31:57] [debug] ( javajni.c:817 ) [ 3228] JVM Option[2] > -Djava.class.path=C:\\Postilion\\eSocket.POS\\java;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-configuration-1.10.jar;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-lang-2.6.jar;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-logging-1.2.jar;C:\\Postilion\\eSocket.POS\\bin\\bcpkix-jdk15.jar;C:\\Postilion\\eSocket.POS\\bin\\bcprov-jdk15.jar;C:\\Postilion\\eSocket.POS\\bin\\comm.jar;C:\\Postilion\\eSocket.POS\\bin\\esocket-tools-log4j.jar;C:\\Postilion\\eSocket.POS\\bin\\esocket-tools.jar;C:\\Postilion\\eSocket.POS\\bin\\hsqldb-2.3.4.jar;C:\\Postilion\\eSocket.POS\\bin\\log4j-api-2.13.3.jar;C:\\Postilion\\eSocket.POS\\bin\\log4j-core-2.13.3.jar;C:\\Postilion\\eSocket.POS\\bin\\mssql-jdbc-8.2.2.jre8.jar;C:\\Postilion\\eSocket.POS\\bin\\postespos-sdk.jar;C:\\Postilion\\eSocket.POS\\bin\\commons-daemon.jar;C:\\Postilion\\eSocket.POS\\bin\\endorsed\\xercesImpl.jar;C:\\Postilion\\eSocket.POS\\bin\\endorsed\\xml-apis.jar;C:\\Postilion\\eSocket.POS\\bin\\jai_codec.jar;C:\\Postilion\\eSocket.POS\\bin\\j > See the service log attached. > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (DAEMON-442) ProcRun classpath limitation of 1010 characters truncates the classpath string for many libraries on the classpath
[ https://issues.apache.org/jira/browse/DAEMON-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528724#comment-17528724 ] Mark Thomas commented on DAEMON-442: This is just log truncation. The full class path will still be available to the Java process. > ProcRun classpath limitation of 1010 characters truncates the classpath > string for many libraries on the classpath > -- > > Key: DAEMON-442 > URL: https://issues.apache.org/jira/browse/DAEMON-442 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.2.3 >Reporter: Japie vd Linde >Priority: Major > Attachments: Service-Service-Log.2022-04-06.log > > > When installing a service and it has a long java class path, it truncates of > the remainder of the class path which seems to have a 1010 character limit > when specifying a big amount of jars. > > See here where the JVM option shows the classpath being truncated: > [2022-04-06 16:31:57] [debug] ( javajni.c:817 ) [ 3228] JVM Option[2] > -Djava.class.path=C:\\Postilion\\eSocket.POS\\java;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-configuration-1.10.jar;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-lang-2.6.jar;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-logging-1.2.jar;C:\\Postilion\\eSocket.POS\\bin\\bcpkix-jdk15.jar;C:\\Postilion\\eSocket.POS\\bin\\bcprov-jdk15.jar;C:\\Postilion\\eSocket.POS\\bin\\comm.jar;C:\\Postilion\\eSocket.POS\\bin\\esocket-tools-log4j.jar;C:\\Postilion\\eSocket.POS\\bin\\esocket-tools.jar;C:\\Postilion\\eSocket.POS\\bin\\hsqldb-2.3.4.jar;C:\\Postilion\\eSocket.POS\\bin\\log4j-api-2.13.3.jar;C:\\Postilion\\eSocket.POS\\bin\\log4j-core-2.13.3.jar;C:\\Postilion\\eSocket.POS\\bin\\mssql-jdbc-8.2.2.jre8.jar;C:\\Postilion\\eSocket.POS\\bin\\postespos-sdk.jar;C:\\Postilion\\eSocket.POS\\bin\\commons-daemon.jar;C:\\Postilion\\eSocket.POS\\bin\\endorsed\\xercesImpl.jar;C:\\Postilion\\eSocket.POS\\bin\\endorsed\\xml-apis.jar;C:\\Postilion\\eSocket.POS\\bin\\jai_codec.jar;C:\\Postilion\\eSocket.POS\\bin\\j > See the service log attached. > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (DAEMON-442) ProcRun classpath limitation of 1010 characters truncates the classpath string for many libraries on the classpath
[ https://issues.apache.org/jira/browse/DAEMON-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528694#comment-17528694 ] Mark Thomas commented on DAEMON-442: Windows version ? > ProcRun classpath limitation of 1010 characters truncates the classpath > string for many libraries on the classpath > -- > > Key: DAEMON-442 > URL: https://issues.apache.org/jira/browse/DAEMON-442 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.2.3 >Reporter: Japie vd Linde >Priority: Major > Attachments: Service-Service-Log.2022-04-06.log > > > When installing a service and it has a long java class path, it truncates of > the remainder of the class path which seems to have a 1010 character limit > when specifying a big amount of jars. > > See here where the JVM option shows the classpath being truncated: > [2022-04-06 16:31:57] [debug] ( javajni.c:817 ) [ 3228] JVM Option[2] > -Djava.class.path=C:\\Postilion\\eSocket.POS\\java;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-configuration-1.10.jar;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-lang-2.6.jar;C:\\Postilion\\eSocket.POS\\CXPI\\lib\\commons-logging-1.2.jar;C:\\Postilion\\eSocket.POS\\bin\\bcpkix-jdk15.jar;C:\\Postilion\\eSocket.POS\\bin\\bcprov-jdk15.jar;C:\\Postilion\\eSocket.POS\\bin\\comm.jar;C:\\Postilion\\eSocket.POS\\bin\\esocket-tools-log4j.jar;C:\\Postilion\\eSocket.POS\\bin\\esocket-tools.jar;C:\\Postilion\\eSocket.POS\\bin\\hsqldb-2.3.4.jar;C:\\Postilion\\eSocket.POS\\bin\\log4j-api-2.13.3.jar;C:\\Postilion\\eSocket.POS\\bin\\log4j-core-2.13.3.jar;C:\\Postilion\\eSocket.POS\\bin\\mssql-jdbc-8.2.2.jre8.jar;C:\\Postilion\\eSocket.POS\\bin\\postespos-sdk.jar;C:\\Postilion\\eSocket.POS\\bin\\commons-daemon.jar;C:\\Postilion\\eSocket.POS\\bin\\endorsed\\xercesImpl.jar;C:\\Postilion\\eSocket.POS\\bin\\endorsed\\xml-apis.jar;C:\\Postilion\\eSocket.POS\\bin\\jai_codec.jar;C:\\Postilion\\eSocket.POS\\bin\\j > See the service log attached. > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (DAEMON-441) When installing a Windows service using Commons Daemon 1.3.0 the errorlevel is -1073741819
[
https://issues.apache.org/jira/browse/DAEMON-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528689#comment-17528689
]
Mark Thomas commented on DAEMON-441:
You can find a development build of 1.3.1 at
[https://people.apache.org/~markt/dev/commons-daemon-1.3.1-dev/]
It is probably stating the obvious but:
* this isn't an official release
* these binaries are intended for testing only
* use them at your own risk
Also, because they aren't official releases, they aren't signed. You'll likely
see a few more warnings as a result.
> When installing a Windows service using Commons Daemon 1.3.0 the errorlevel
> is -1073741819
> --
>
> Key: DAEMON-441
> URL: https://issues.apache.org/jira/browse/DAEMON-441
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.0
> Environment: Windows 2016 Datacenter
>Reporter: Brian Andle
>Priority: Major
> Attachments: Command_Prompt.png
>
>
> When attempting to use prunsrv.exe on Windows 2016 to create a service a
> Windows Event error is logged and the errorlevel is returned as -1073741819
> Running the following command:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=My Service
> --DisplayName=My Service {code}
> Results in the following Windows Event Log entry
>
> {code:java}
> Faulting application name: prunsrv.exe, version: 1.3.0.0, time stamp:
> 0x622b3ac0
> Faulting module name: prunsrv.exe, version: 1.3.0.0, time stamp: 0x622b3ac0
> Exception code: 0xc005
> Fault offset: 0x6e70
> Faulting process id: 0x1d88
> Faulting application start time: 0x01d845f90eb4351a
> Faulting application path: C:\myfolder\prunsrv.exe
> Faulting module path: C:\myfolder\prunsrv.exe
> Report Id: 409b7098-42bd-4036-aa61-b19eecdb1bd7
> Faulting package full name:
> Faulting package-relative application ID: {code}
> Doing an echo %errorlevel% shows -1073741819 instead of the expected 0
> Version 1.2.4.0 works correctly on both Windows 10 and 2016
> *NOTE:* The service does appear to actually install on 2016, however most
> deploy scripts will expect an error level of 0 and will fail if a non 0 value
> it returned.
> h3. Workaround
> Define a *--LogPath* value and do not use the default
> %SystemRoot%\System32\LogFiles\Apache path
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (DAEMON-441) When installing a Windows service using Commons Daemon 1.3.0 the errorlevel is -1073741819
[
https://issues.apache.org/jira/browse/DAEMON-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528244#comment-17528244
]
Mark Thomas commented on DAEMON-441:
I found a handful of errors looking in to this. The root cause of the specific
issue was attempting to set permissions on a null path when there wasn't a
specific LogPath defined.
It would be helpful if you can confirm the fix before I do the release. Are you
able to build procrun from source or do you want me to provide you with some
binaries to test?
> When installing a Windows service using Commons Daemon 1.3.0 the errorlevel
> is -1073741819
> --
>
> Key: DAEMON-441
> URL: https://issues.apache.org/jira/browse/DAEMON-441
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.0
> Environment: Windows 2016 Datacenter
>Reporter: Brian Andle
>Priority: Major
> Attachments: Command_Prompt.png
>
>
> When attempting to use prunsrv.exe on Windows 2016 to create a service a
> Windows Event error is logged and the errorlevel is returned as -1073741819
> Running the following command:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=My Service
> --DisplayName=My Service {code}
> Results in the following Windows Event Log entry
>
> {code:java}
> Faulting application name: prunsrv.exe, version: 1.3.0.0, time stamp:
> 0x622b3ac0
> Faulting module name: prunsrv.exe, version: 1.3.0.0, time stamp: 0x622b3ac0
> Exception code: 0xc005
> Fault offset: 0x6e70
> Faulting process id: 0x1d88
> Faulting application start time: 0x01d845f90eb4351a
> Faulting application path: C:\myfolder\prunsrv.exe
> Faulting module path: C:\myfolder\prunsrv.exe
> Report Id: 409b7098-42bd-4036-aa61-b19eecdb1bd7
> Faulting package full name:
> Faulting package-relative application ID: {code}
> Doing an echo %errorlevel% shows -1073741819 instead of the expected 0
> Version 1.2.4.0 works correctly on both Windows 10 and 2016
> *NOTE:* The service does appear to actually install on 2016, however most
> deploy scripts will expect an error level of 0 and will fail if a non 0 value
> it returned.
> h3. Workaround
> Define a *--LogPath* value and do not use the default
> %SystemRoot%\System32\LogFiles\Apache path
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (DAEMON-441) When installing a Windows service using Commons Daemon 1.3.0 the errorlevel is -1073741819
[
https://issues.apache.org/jira/browse/DAEMON-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524415#comment-17524415
]
Mark Thomas commented on DAEMON-441:
My current thinking is we need to improve the error handling so the cause of
the failure is clear.
We might also want to consider switching the default log file location. The old
location made sense if running as LocalSystem but as of 1.2.0 the service runs
as LocalService by default. That said, I'm a little reluctant to change the
defaults. Simply reporting the error - with a suggestion to specify a location
for the log files - might be the better approach.
> When installing a Windows service using Commons Daemon 1.3.0 the errorlevel
> is -1073741819
> --
>
> Key: DAEMON-441
> URL: https://issues.apache.org/jira/browse/DAEMON-441
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.0
> Environment: Windows 2016 Datacenter
>Reporter: Brian Andle
>Priority: Major
> Attachments: Command_Prompt.png
>
>
> When attempting to use prunsrv.exe on Windows 2016 to create a service a
> Windows Event error is logged and the errorlevel is returned as -1073741819
> Running the following command:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=My Service
> --DisplayName=My Service {code}
> Results in the following Windows Event Log entry
>
> {code:java}
> Faulting application name: prunsrv.exe, version: 1.3.0.0, time stamp:
> 0x622b3ac0
> Faulting module name: prunsrv.exe, version: 1.3.0.0, time stamp: 0x622b3ac0
> Exception code: 0xc005
> Fault offset: 0x6e70
> Faulting process id: 0x1d88
> Faulting application start time: 0x01d845f90eb4351a
> Faulting application path: C:\myfolder\prunsrv.exe
> Faulting module path: C:\myfolder\prunsrv.exe
> Report Id: 409b7098-42bd-4036-aa61-b19eecdb1bd7
> Faulting package full name:
> Faulting package-relative application ID: {code}
> Doing an echo %errorlevel% shows -1073741819 instead of the expected 0
> Version 1.2.4.0 works correctly on both Windows 10 and 2016
> *NOTE:* The service does appear to actually install on 2016, however most
> deploy scripts will expect an error level of 0 and will fail if a non 0 value
> it returned.
> h3. Workaround
> Define a *--LogPath* value and do not use the default
> %SystemRoot%\System32\LogFiles\Apache path
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (DAEMON-49) [daemon] numeric and multiple parameter arguments are not read from environment
[ https://issues.apache.org/jira/browse/DAEMON-49 ] Mark Thomas deleted comment on DAEMON-49: --- was (Author: JIRAUSER288119): [agario|https://puffnachrichten.com/tech/agario-boston/13741/] [agario|https://alcoholink.community/members/agario/] agario [agario|https://www.msn.com/ar-ae/health/search?q=agario.boston] [agario|https://www.msn.com/ar-ae/health/search?q=www.zafer2.com] [agario|https://www.msn.com/ar-ae/health/search?q=mt2.org] [agario|https://www.msn.com/ar-ae/health/search?q=altyazilifilm.cc] [agario|https://www.msn.com/ar-ae/health/search?q=editsizserverler.org] [agario|https://pagespeed.web.dev/report?url=https%3A%2F%2Fagario.boston%2F] [agario|https://gtmetrix.com/reports/agario.boston/XfCIbNyQ/] [agario|https://www.webpagetest.org/result/220417_BiDc6X_FZ/] [agario online|https://agarioonline.org/] [agario game|https://agariogame.net/] [agario|https://agario.id/] [agar.io|https://agar.cc/] [agario unblocked|https://agario.nl/] [agario|https://agario.boston/] [agario unblocked|https://agar.rip/play/] [agario|https://agario.org.uk/play/] > [daemon] numeric and multiple parameter arguments are not read from > environment > --- > > Key: DAEMON-49 > URL: https://issues.apache.org/jira/browse/DAEMON-49 > Project: Commons Daemon > Issue Type: Bug >Affects Versions: 1.0.1 > Environment: Operating System: other > Platform: PC >Reporter: Robert Longson >Priority: Minor > Fix For: 1.0.2 > > Attachments: ASF.LICENSE.NOT.GRANTED--intenv.txt > > > prunsrv does not read numeric or multiple parameter arguments from the > environment properly. > e.g. > set PR_STOPPARAMS=stop > set PR_STOPTIMEOUT=20 > prunsrv //IS//XXX > will result in the service XXX having neither value set, only ordinary string > parameters work e.g. set PR_STDERROR=auto > Such parameters can be set on the command line as a workaround. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DAEMON-441) When installing a Windows service using Commons Daemon 1.3.0 the errorlevel is -1073741819
[
https://issues.apache.org/jira/browse/DAEMON-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516082#comment-17516082
]
Mark Thomas commented on DAEMON-441:
I suspect Daemon is failing to configure the permissions correctly for the log
directory. Are there are log messages and/or console messages reporting
problems?
> When installing a Windows service using Commons Daemon 1.3.0 the errorlevel
> is -1073741819
> --
>
> Key: DAEMON-441
> URL: https://issues.apache.org/jira/browse/DAEMON-441
> Project: Commons Daemon
> Issue Type: Bug
>Affects Versions: 1.3.0
> Environment: Windows 2016 Datacenter
>Reporter: Brian Andle
>Priority: Major
>
> When attempting to use prunsrv.exe on Windows 2016 to create a service a
> Windows Event error is logged and the errorlevel is returned as -1073741819
> Running the following command:
> {code:java}
> prunsrv.exe //IS/MyService --Startup=auto --Description=My Service
> --DisplayName=My Service {code}
> Results in the following Windows Event Log entry
>
> {code:java}
> Faulting application name: prunsrv.exe, version: 1.3.0.0, time stamp:
> 0x622b3ac0
> Faulting module name: prunsrv.exe, version: 1.3.0.0, time stamp: 0x622b3ac0
> Exception code: 0xc005
> Fault offset: 0x6e70
> Faulting process id: 0x1d88
> Faulting application start time: 0x01d845f90eb4351a
> Faulting application path: C:\myfolder\prunsrv.exe
> Faulting module path: C:\myfolder\prunsrv.exe
> Report Id: 409b7098-42bd-4036-aa61-b19eecdb1bd7
> Faulting package full name:
> Faulting package-relative application ID: {code}
> Doing an echo %errorlevel% shows -1073741819 instead of the expected 0
> On Windows 10 an Access Is Denied error is returned
> Version 1.2.4.0 works correctly on both Windows 10 and 2016
> *NOTE:* The service does appear to actually install on 2016, however most
> deploy scripts will expect an error level of 0 and will fail if a non 0 value
> it returned.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (DAEMON-434) The data area passed to a system call is too small
[ https://issues.apache.org/jira/browse/DAEMON-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-434. Resolution: Cannot Reproduce > The data area passed to a system call is too small > -- > > Key: DAEMON-434 > URL: https://issues.apache.org/jira/browse/DAEMON-434 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.2.4 > Environment: Server 2019 > OpenJDK 11 > hSQLdb 2.6 >Reporter: Dick Hildreth >Priority: Major > > Batch file: > REM hSQLdb Windows Service Batch File. > REM Install hSQLdb as Service Using Apache Commons Daemon Programs. > REM The command below will install hSQLdb as a Service using list of > Databases from server.properties. > prunsrv update hSQLdb --DisplayName="hSQLdb Database" --Description="hSQLdb > Database Service" --Startup=automatic --StartMode=Java --StopMode=Java > --JvmMx=128 --StartPath=C:\hSQLdb --Classpath=C:\hSQLdb\lib\hsqldb.jar > --StartClass=org.hsqldb.server.Server --StartParams=--props > ++StartParams=C:/hSQLdb/server.properties > REM Start The Service. > prunsrv start hSQLdb > > The service is installed properly but, when trying to start it, the subject > error is returned. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (DAEMON-439) prunsrv '--Startup=delayed' sets manual mode instead
[ https://issues.apache.org/jira/browse/DAEMON-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-439. Fix Version/s: 1.3.0 Resolution: Fixed Support was implemented for update for not for initial install. It now works for both. > prunsrv '--Startup=delayed' sets manual mode instead > > > Key: DAEMON-439 > URL: https://issues.apache.org/jira/browse/DAEMON-439 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.2.4 >Reporter: Gregory Kotsaftis >Priority: Minor > Fix For: 1.3.0 > > > Trying to replace AUTO for DELAYED in my long used custom service > installation script, defaults to MANUAL. It seems auto and manual are set as > expected but delayed is never set! > c:\prunsrv.exe //IS//MyServer --DisplayName="My Server" --Description="My > application server" --Install="c:\prunsrv.exe" --Startup=delayed > --StartMode=exe --StartImage="c:\app\myexe.exe" --StartPath="c:\app" > --StartParams=start --StopMode=exe --StopImage="c:\app\myexe.exe" > --StopPath="c:\app" --StopParams=stop --LogPath="c:\app" --LogPrefix=myserver > --LogLevel=info --StdOutput=auto --StdError=auto -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (DAEMON-437) prunsrv: Better not to redirect stdout/stderr during service installation?
[ https://issues.apache.org/jira/browse/DAEMON-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-437. Resolution: Fixed I've fixed the permissions issues. Setting / changing the service user will grant that user access to the logging directory. The issue of separate log files should be raised as an enhancement in a new issue. > prunsrv: Better not to redirect stdout/stderr during service installation? > -- > > Key: DAEMON-437 > URL: https://issues.apache.org/jira/browse/DAEMON-437 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.2.4 >Reporter: Rainer Jung >Priority: Major > Fix For: 1.3.0 > > > I observed the following behavior when using prunsrv: > I call it with //IS//MyService and more arguments to install a Tomcat > service. Especially I use the default LocalSystem user as the user who will > run the installed service and the arguments: > --StdOutput auto ^ > --StdError auto ^ > to redirect stdout and stderr to the default files. > To install the service I use a user with Administrator privileges. Running > prunsrv to install the service now already creates the redirected stdout and > stderr files, but only writable by Administrator. > When I start the service after this service installation, it can not write to > the redirected stdout and stderr files, because it runs as a lower privileged > LocalSystem account. > Before calling redirectStdStreams() in apps/prunsrv/prunsrv.c, there is > already a special case if prunsrv was called with //TS (Run Service as > console application): > 1692 /* In debug mode allways use console */ > 1693 if (lpCmdline->dwCmdIndex != 1) > 1694 gStdwrap.szStdOutFilename = SO_STDOUTPUT; > 1695 gStdwrap.szStdErrFilename = SO_STDERROR; > 1696 } > I wonder, whether it wouldn't be better to not set the redirection file names > for other dwCmdIndex values as well. Here's the list of indexes from the > source code: > 76 L"RS", /* 2 Run Service */ > 77 L"ES", /* 3 Execute start */ > 78 L"SS", /* 4 Stop Service */ > 79 L"US", /* 5 Update Service parameters */ > 80 L"IS", /* 6 Install Service */ > 81 L"DS", /* 7 Delete Service */ > 82 L"?", /* 8 Help */ > 83 L"VS", /* 9 Version */ > IMHO 5-9 are candidates, maybe 4 and 3 as well. At least for those I would > expect that they were executed on the console and stdout/stderr would also be > expected there. But I might not be aware of use cases with other needs. > The normal prunsrv log file does have the same permission problem. But since > it contains log info about what action had been done, I am not so sure, > whether one can simply write that to stdout instead. But maybe one could use > a different default file name line MyService.manage.2021-12-07.log instead of > MyService.2021-12-07.log for the above indexes. Not nice, but I don't have a > better idea yet. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DAEMON-437) prunsrv: Better not to redirect stdout/stderr during service installation?
[ https://issues.apache.org/jira/browse/DAEMON-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17501259#comment-17501259 ] Mark Thomas commented on DAEMON-437: I am currently working on the permissions issue. It turned out to be a little more complex that I first thought. I am currently implementing a solution that grants the specified user read, write & execute permissions to the logs directory (with inheritance enabled) any time the service user is specified/changed. That should address the permissions issues as best we can. Separating logs for configuration changes and starting/stopping the service is a separate issue and probably needs to be discussed as such. I'm not sure it makes sense to separate these. The service will log using whatever mechanism the daemonized Java app is configured to use. I'm beginning to think having all the Commons Daemon specific logging (installation, configuration, start, stop) in a single log makes more sense. I'm thinking of the following sequence: * install * configure * fail to start due to config error * fix config * start I think having the daemon logs for all of that in one log file would be easier to follow. I intend to resolve this issue once the permissions issue is addressed. The separating logs issue should move to a new issue. > prunsrv: Better not to redirect stdout/stderr during service installation? > -- > > Key: DAEMON-437 > URL: https://issues.apache.org/jira/browse/DAEMON-437 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.2.4 >Reporter: Rainer Jung >Priority: Major > Fix For: 1.2.5 > > > I observed the following behavior when using prunsrv: > I call it with //IS//MyService and more arguments to install a Tomcat > service. Especially I use the default LocalSystem user as the user who will > run the installed service and the arguments: > --StdOutput auto ^ > --StdError auto ^ > to redirect stdout and stderr to the default files. > To install the service I use a user with Administrator privileges. Running > prunsrv to install the service now already creates the redirected stdout and > stderr files, but only writable by Administrator. > When I start the service after this service installation, it can not write to > the redirected stdout and stderr files, because it runs as a lower privileged > LocalSystem account. > Before calling redirectStdStreams() in apps/prunsrv/prunsrv.c, there is > already a special case if prunsrv was called with //TS (Run Service as > console application): > 1692 /* In debug mode allways use console */ > 1693 if (lpCmdline->dwCmdIndex != 1) > 1694 gStdwrap.szStdOutFilename = SO_STDOUTPUT; > 1695 gStdwrap.szStdErrFilename = SO_STDERROR; > 1696 } > I wonder, whether it wouldn't be better to not set the redirection file names > for other dwCmdIndex values as well. Here's the list of indexes from the > source code: > 76 L"RS", /* 2 Run Service */ > 77 L"ES", /* 3 Execute start */ > 78 L"SS", /* 4 Stop Service */ > 79 L"US", /* 5 Update Service parameters */ > 80 L"IS", /* 6 Install Service */ > 81 L"DS", /* 7 Delete Service */ > 82 L"?", /* 8 Help */ > 83 L"VS", /* 9 Version */ > IMHO 5-9 are candidates, maybe 4 and 3 as well. At least for those I would > expect that they were executed on the console and stdout/stderr would also be > expected there. But I might not be aware of use cases with other needs. > The normal prunsrv log file does have the same permission problem. But since > it contains log info about what action had been done, I am not so sure, > whether one can simply write that to stdout instead. But maybe one could use > a different default file name line MyService.manage.2021-12-07.log instead of > MyService.2021-12-07.log for the above indexes. Not nice, but I don't have a > better idea yet. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (DAEMON-438) prunsrv: stdout/stderr redirection does not work if log directory didn't exist
[ https://issues.apache.org/jira/browse/DAEMON-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-438. Resolution: Duplicate > prunsrv: stdout/stderr redirection does not work if log directory didn't exist > -- > > Key: DAEMON-438 > URL: https://issues.apache.org/jira/browse/DAEMON-438 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.2.4 >Reporter: Hansi >Priority: Minor > > If you enable stdout/stderr redirection (auto) and the log directory (given > by LogPath) does not exist then Procrun will create the missing directory and > will create the files commons-daemon--xx-xx.log, > ...-stdout--xx-xx.log, and ...-stderr--xx-xx.log, but the two latter > files won't be populated (filesizes stay at 0). > Instead of fixing this issue in Procrun itself, imho, it might be sufficient > to state this limitation in the documentation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DAEMON-437) prunsrv: Better not to redirect stdout/stderr during service installation?
[ https://issues.apache.org/jira/browse/DAEMON-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17484647#comment-17484647 ] Mark Thomas commented on DAEMON-437: Looking at the source code, the issue of multiple processes writing to the prunsrv log file shouldn't be an issue unless multiple users are trying to run commands at the same time. The changes to handle that use case would be significant and I'm not proposing we support that. So, think we have two choices. Drop the prunsrv log entirely and just use stdout/stderr. That would mean losing the log of actions taken which I think would be a step backwards. The other option is to configure the log file to allow the service user to write to it. I think that is the way to go. Thoughts? > prunsrv: Better not to redirect stdout/stderr during service installation? > -- > > Key: DAEMON-437 > URL: https://issues.apache.org/jira/browse/DAEMON-437 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.2.4 >Reporter: Rainer Jung >Priority: Major > Fix For: 1.2.5 > > > I observed the following behavior when using prunsrv: > I call it with //IS//MyService and more arguments to install a Tomcat > service. Especially I use the default LocalSystem user as the user who will > run the installed service and the arguments: > --StdOutput auto ^ > --StdError auto ^ > to redirect stdout and stderr to the default files. > To install the service I use a user with Administrator privileges. Running > prunsrv to install the service now already creates the redirected stdout and > stderr files, but only writable by Administrator. > When I start the service after this service installation, it can not write to > the redirected stdout and stderr files, because it runs as a lower privileged > LocalSystem account. > Before calling redirectStdStreams() in apps/prunsrv/prunsrv.c, there is > already a special case if prunsrv was called with //TS (Run Service as > console application): > 1692 /* In debug mode allways use console */ > 1693 if (lpCmdline->dwCmdIndex != 1) > 1694 gStdwrap.szStdOutFilename = SO_STDOUTPUT; > 1695 gStdwrap.szStdErrFilename = SO_STDERROR; > 1696 } > I wonder, whether it wouldn't be better to not set the redirection file names > for other dwCmdIndex values as well. Here's the list of indexes from the > source code: > 76 L"RS", /* 2 Run Service */ > 77 L"ES", /* 3 Execute start */ > 78 L"SS", /* 4 Stop Service */ > 79 L"US", /* 5 Update Service parameters */ > 80 L"IS", /* 6 Install Service */ > 81 L"DS", /* 7 Delete Service */ > 82 L"?", /* 8 Help */ > 83 L"VS", /* 9 Version */ > IMHO 5-9 are candidates, maybe 4 and 3 as well. At least for those I would > expect that they were executed on the console and stdout/stderr would also be > expected there. But I might not be aware of use cases with other needs. > The normal prunsrv log file does have the same permission problem. But since > it contains log info about what action had been done, I am not so sure, > whether one can simply write that to stdout instead. But maybe one could use > a different default file name line MyService.manage.2021-12-07.log instead of > MyService.2021-12-07.log for the above indexes. Not nice, but I don't have a > better idea yet. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (DAEMON-437) prunsrv: Better not to redirect stdout/stderr during service installation?
[ https://issues.apache.org/jira/browse/DAEMON-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas reopened DAEMON-437: Re-open to discuss what to do with the prunsrv log file > prunsrv: Better not to redirect stdout/stderr during service installation? > -- > > Key: DAEMON-437 > URL: https://issues.apache.org/jira/browse/DAEMON-437 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.2.4 >Reporter: Rainer Jung >Priority: Major > Fix For: 1.2.5 > > > I observed the following behavior when using prunsrv: > I call it with //IS//MyService and more arguments to install a Tomcat > service. Especially I use the default LocalSystem user as the user who will > run the installed service and the arguments: > --StdOutput auto ^ > --StdError auto ^ > to redirect stdout and stderr to the default files. > To install the service I use a user with Administrator privileges. Running > prunsrv to install the service now already creates the redirected stdout and > stderr files, but only writable by Administrator. > When I start the service after this service installation, it can not write to > the redirected stdout and stderr files, because it runs as a lower privileged > LocalSystem account. > Before calling redirectStdStreams() in apps/prunsrv/prunsrv.c, there is > already a special case if prunsrv was called with //TS (Run Service as > console application): > 1692 /* In debug mode allways use console */ > 1693 if (lpCmdline->dwCmdIndex != 1) > 1694 gStdwrap.szStdOutFilename = SO_STDOUTPUT; > 1695 gStdwrap.szStdErrFilename = SO_STDERROR; > 1696 } > I wonder, whether it wouldn't be better to not set the redirection file names > for other dwCmdIndex values as well. Here's the list of indexes from the > source code: > 76 L"RS", /* 2 Run Service */ > 77 L"ES", /* 3 Execute start */ > 78 L"SS", /* 4 Stop Service */ > 79 L"US", /* 5 Update Service parameters */ > 80 L"IS", /* 6 Install Service */ > 81 L"DS", /* 7 Delete Service */ > 82 L"?", /* 8 Help */ > 83 L"VS", /* 9 Version */ > IMHO 5-9 are candidates, maybe 4 and 3 as well. At least for those I would > expect that they were executed on the console and stdout/stderr would also be > expected there. But I might not be aware of use cases with other needs. > The normal prunsrv log file does have the same permission problem. But since > it contains log info about what action had been done, I am not so sure, > whether one can simply write that to stdout instead. But maybe one could use > a different default file name line MyService.manage.2021-12-07.log instead of > MyService.2021-12-07.log for the above indexes. Not nice, but I don't have a > better idea yet. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (DAEMON-437) prunsrv: Better not to redirect stdout/stderr during service installation?
[ https://issues.apache.org/jira/browse/DAEMON-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-437. Fix Version/s: 1.2.5 Resolution: Fixed FYI - a review of the docs didn't identify any updates required. > prunsrv: Better not to redirect stdout/stderr during service installation? > -- > > Key: DAEMON-437 > URL: https://issues.apache.org/jira/browse/DAEMON-437 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.2.4 >Reporter: Rainer Jung >Priority: Major > Fix For: 1.2.5 > > > I observed the following behavior when using prunsrv: > I call it with //IS//MyService and more arguments to install a Tomcat > service. Especially I use the default LocalSystem user as the user who will > run the installed service and the arguments: > --StdOutput auto ^ > --StdError auto ^ > to redirect stdout and stderr to the default files. > To install the service I use a user with Administrator privileges. Running > prunsrv to install the service now already creates the redirected stdout and > stderr files, but only writable by Administrator. > When I start the service after this service installation, it can not write to > the redirected stdout and stderr files, because it runs as a lower privileged > LocalSystem account. > Before calling redirectStdStreams() in apps/prunsrv/prunsrv.c, there is > already a special case if prunsrv was called with //TS (Run Service as > console application): > 1692 /* In debug mode allways use console */ > 1693 if (lpCmdline->dwCmdIndex != 1) > 1694 gStdwrap.szStdOutFilename = SO_STDOUTPUT; > 1695 gStdwrap.szStdErrFilename = SO_STDERROR; > 1696 } > I wonder, whether it wouldn't be better to not set the redirection file names > for other dwCmdIndex values as well. Here's the list of indexes from the > source code: > 76 L"RS", /* 2 Run Service */ > 77 L"ES", /* 3 Execute start */ > 78 L"SS", /* 4 Stop Service */ > 79 L"US", /* 5 Update Service parameters */ > 80 L"IS", /* 6 Install Service */ > 81 L"DS", /* 7 Delete Service */ > 82 L"?", /* 8 Help */ > 83 L"VS", /* 9 Version */ > IMHO 5-9 are candidates, maybe 4 and 3 as well. At least for those I would > expect that they were executed on the console and stdout/stderr would also be > expected there. But I might not be aware of use cases with other needs. > The normal prunsrv log file does have the same permission problem. But since > it contains log info about what action had been done, I am not so sure, > whether one can simply write that to stdout instead. But maybe one could use > a different default file name line MyService.manage.2021-12-07.log instead of > MyService.2021-12-07.log for the above indexes. Not nice, but I don't have a > better idea yet. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DAEMON-437) prunsrv: Better not to redirect stdout/stderr during service installation?
[ https://issues.apache.org/jira/browse/DAEMON-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483278#comment-17483278 ] Mark Thomas commented on DAEMON-437: Another reason to limit this to RS occurred to me. It we keep the redirection enabled for any other commands and the service is running we'll have two processes trying to write to the same file which is never a good idea. I am going to proceed with limiting this to just RS along with documentation updates as appropriate. > prunsrv: Better not to redirect stdout/stderr during service installation? > -- > > Key: DAEMON-437 > URL: https://issues.apache.org/jira/browse/DAEMON-437 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.2.4 >Reporter: Rainer Jung >Priority: Major > > I observed the following behavior when using prunsrv: > I call it with //IS//MyService and more arguments to install a Tomcat > service. Especially I use the default LocalSystem user as the user who will > run the installed service and the arguments: > --StdOutput auto ^ > --StdError auto ^ > to redirect stdout and stderr to the default files. > To install the service I use a user with Administrator privileges. Running > prunsrv to install the service now already creates the redirected stdout and > stderr files, but only writable by Administrator. > When I start the service after this service installation, it can not write to > the redirected stdout and stderr files, because it runs as a lower privileged > LocalSystem account. > Before calling redirectStdStreams() in apps/prunsrv/prunsrv.c, there is > already a special case if prunsrv was called with //TS (Run Service as > console application): > 1692 /* In debug mode allways use console */ > 1693 if (lpCmdline->dwCmdIndex != 1) > 1694 gStdwrap.szStdOutFilename = SO_STDOUTPUT; > 1695 gStdwrap.szStdErrFilename = SO_STDERROR; > 1696 } > I wonder, whether it wouldn't be better to not set the redirection file names > for other dwCmdIndex values as well. Here's the list of indexes from the > source code: > 76 L"RS", /* 2 Run Service */ > 77 L"ES", /* 3 Execute start */ > 78 L"SS", /* 4 Stop Service */ > 79 L"US", /* 5 Update Service parameters */ > 80 L"IS", /* 6 Install Service */ > 81 L"DS", /* 7 Delete Service */ > 82 L"?", /* 8 Help */ > 83 L"VS", /* 9 Version */ > IMHO 5-9 are candidates, maybe 4 and 3 as well. At least for those I would > expect that they were executed on the console and stdout/stderr would also be > expected there. But I might not be aware of use cases with other needs. > The normal prunsrv log file does have the same permission problem. But since > it contains log info about what action had been done, I am not so sure, > whether one can simply write that to stdout instead. But maybe one could use > a different default file name line MyService.manage.2021-12-07.log instead of > MyService.2021-12-07.log for the above indexes. Not nice, but I don't have a > better idea yet. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DAEMON-437) prunsrv: Better not to redirect stdout/stderr during service installation?
[ https://issues.apache.org/jira/browse/DAEMON-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17482569#comment-17482569 ] Mark Thomas commented on DAEMON-437: I'm currently thinking the same as you. Anything other than RS shouldn't redirect. Assuming we make this change, we can clarify the behaviour in the documentation as well. > prunsrv: Better not to redirect stdout/stderr during service installation? > -- > > Key: DAEMON-437 > URL: https://issues.apache.org/jira/browse/DAEMON-437 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.2.4 >Reporter: Rainer Jung >Priority: Major > > I observed the following behavior when using prunsrv: > I call it with //IS//MyService and more arguments to install a Tomcat > service. Especially I use the default LocalSystem user as the user who will > run the installed service and the arguments: > --StdOutput auto ^ > --StdError auto ^ > to redirect stdout and stderr to the default files. > To install the service I use a user with Administrator privileges. Running > prunsrv to install the service now already creates the redirected stdout and > stderr files, but only writable by Administrator. > When I start the service after this service installation, it can not write to > the redirected stdout and stderr files, because it runs as a lower privileged > LocalSystem account. > Before calling redirectStdStreams() in apps/prunsrv/prunsrv.c, there is > already a special case if prunsrv was called with //TS (Run Service as > console application): > 1692 /* In debug mode allways use console */ > 1693 if (lpCmdline->dwCmdIndex != 1) > 1694 gStdwrap.szStdOutFilename = SO_STDOUTPUT; > 1695 gStdwrap.szStdErrFilename = SO_STDERROR; > 1696 } > I wonder, whether it wouldn't be better to not set the redirection file names > for other dwCmdIndex values as well. Here's the list of indexes from the > source code: > 76 L"RS", /* 2 Run Service */ > 77 L"ES", /* 3 Execute start */ > 78 L"SS", /* 4 Stop Service */ > 79 L"US", /* 5 Update Service parameters */ > 80 L"IS", /* 6 Install Service */ > 81 L"DS", /* 7 Delete Service */ > 82 L"?", /* 8 Help */ > 83 L"VS", /* 9 Version */ > IMHO 5-9 are candidates, maybe 4 and 3 as well. At least for those I would > expect that they were executed on the console and stdout/stderr would also be > expected there. But I might not be aware of use cases with other needs. > The normal prunsrv log file does have the same permission problem. But since > it contains log info about what action had been done, I am not so sure, > whether one can simply write that to stdout instead. But maybe one could use > a different default file name line MyService.manage.2021-12-07.log instead of > MyService.2021-12-07.log for the above indexes. Not nice, but I don't have a > better idea yet. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DAEMON-336) prunsrv crash on service stop
[ https://issues.apache.org/jira/browse/DAEMON-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17477331#comment-17477331 ] Mark Thomas commented on DAEMON-336: I've tried to reproduce the issue with the information here and a simple test service but I am unable to. I'd still like to be able to recreate this before applying any patch. > prunsrv crash on service stop > - > > Key: DAEMON-336 > URL: https://issues.apache.org/jira/browse/DAEMON-336 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Windows 8.1 with Java 8 64bit, Java mode >Reporter: Volker Berlin >Priority: Major > > If the service should be stop then it crash. In the event log you can see: > Name der fehlerhaften Anwendung: foo-serverService.exe, Version: 1.0.15.0, > Zeitstempel: 0x51543b9d > Name des fehlerhaften Moduls: ntdll.dll, Version: 6.3.9600.17736, > Zeitstempel: 0x550f4336 > Ausnahmecode: 0xc005 > Fehleroffset: 0x00035150 > ID des fehlerhaften Prozesses: 0x1578 > Startzeit der fehlerhaften Anwendung: 0x01d0be119603c23f > Pfad der fehlerhaften Anwendung: C:\Program Files\foo > Server\foo-serverService.exe > Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\ntdll.dll > Berichtskennung: da5b2537-2a04-11e5-8063-7427ea3e8675 > Vollständiger Name des fehlerhaften Pakets: > Anwendungs-ID, die relativ zum fehlerhaften Paket ist: -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DAEMON-436) jsvc Boot failure
[ https://issues.apache.org/jira/browse/DAEMON-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463753#comment-17463753 ] Mark Thomas commented on DAEMON-436: Typo "compare" -> "compile". > jsvc Boot failure > - > > Key: DAEMON-436 > URL: https://issues.apache.org/jira/browse/DAEMON-436 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.2.4 > Environment: 在aix7.1.3环境上编译jsvc通过了，但是启动的时候出现在Cannot dynamically link > to /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so，我使用的java version > "1.8.0_311"，IBM J9 VM (build 2.9, JRE 1.8.0 AIX ppc64-64-Bit Compressed > References 20211022_15212 (JIT enabled, AOT enabled) >Reporter: sunly >Priority: Major > Labels: patch > Attachments: minion_jsvc.sh > > Original Estimate: 12h > Remaining Estimate: 12h > > java应用，在aix7.1.3上启动jsvc应用失败，出现一下问题： > Switching umask from 022 to 022 > Using default JVM in /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so > Attemtping to load library /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so > Cannot dynamically link to /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so > Could not load module /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so. > System error: Exec format error > java_init failed > remove_pid_file: open /home/minion/cc-product-minion/temp/miniond.pid: fd=3 > Service exit with a return value of 1 > 这是启动脚本：请看附件 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DAEMON-436) jsvc 启动失败
[
https://issues.apache.org/jira/browse/DAEMON-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463151#comment-17463151
]
Mark Thomas commented on DAEMON-436:
Translation of the description:
{code:java}
For java applications, the jsvc application fails to start on aix7.1.3, and the
following problems occur:
Switching umask from 022 to 022
Using default JVM in /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so
Attemtping to load library /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so
Cannot dynamically link to /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so
Could not load module /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so.
System error: Exec format error
java_init failed
remove_pid_file: open /home/minion/cc-product-minion/temp/miniond.pid: fd=3
Service exit with a return value of 1
This is the startup script: please see the attachment {code}
> jsvc 启动失败
> -
>
> Key: DAEMON-436
> URL: https://issues.apache.org/jira/browse/DAEMON-436
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.2.4
> Environment: 在aix7.1.3环境上编译jsvc通过了，但是启动的时候出现在Cannot dynamically link
> to /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so，我使用的java version
> "1.8.0_311"，IBM J9 VM (build 2.9, JRE 1.8.0 AIX ppc64-64-Bit Compressed
> References 20211022_15212 (JIT enabled, AOT enabled)
>Reporter: sunly
>Priority: Major
> Labels: patch
> Fix For: 1.2.4
>
> Attachments: minion_jsvc.sh
>
> Original Estimate: 12h
> Remaining Estimate: 12h
>
> java应用，在aix7.1.3上启动jsvc应用失败，出现一下问题：
> Switching umask from 022 to 022
> Using default JVM in /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so
> Attemtping to load library /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so
> Cannot dynamically link to /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so
> Could not load module /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so.
> System error: Exec format error
> java_init failed
> remove_pid_file: open /home/minion/cc-product-minion/temp/miniond.pid: fd=3
> Service exit with a return value of 1
> 这是启动脚本：请看附件
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (DAEMON-436) jsvc 启动失败
[ https://issues.apache.org/jira/browse/DAEMON-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463149#comment-17463149 ] Mark Thomas commented on DAEMON-436: There is no need for that sort of attitude. Not everyone speaks English. Google translate usually provides a good enough translation to figure out what the problem is. > jsvc 启动失败 > - > > Key: DAEMON-436 > URL: https://issues.apache.org/jira/browse/DAEMON-436 > Project: Commons Daemon > Issue Type: Bug > Components: Jsvc >Affects Versions: 1.2.4 > Environment: 在aix7.1.3环境上编译jsvc通过了，但是启动的时候出现在Cannot dynamically link > to /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so，我使用的java version > "1.8.0_311"，IBM J9 VM (build 2.9, JRE 1.8.0 AIX ppc64-64-Bit Compressed > References 20211022_15212 (JIT enabled, AOT enabled) >Reporter: sunly >Priority: Major > Labels: patch > Fix For: 1.2.4 > > Attachments: minion_jsvc.sh > > Original Estimate: 12h > Remaining Estimate: 12h > > java应用，在aix7.1.3上启动jsvc应用失败，出现一下问题： > Switching umask from 022 to 022 > Using default JVM in /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so > Attemtping to load library /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so > Cannot dynamically link to /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so > Could not load module /usr/java8_64/jre/lib/ppc64/j9vm/libjvm.so. > System error: Exec format error > java_init failed > remove_pid_file: open /home/minion/cc-product-minion/temp/miniond.pid: fd=3 > Service exit with a return value of 1 > 这是启动脚本：请看附件 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (DAEMON-336) prunsrv crash on service stop
[ https://issues.apache.org/jira/browse/DAEMON-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17412675#comment-17412675 ] Mark Thomas commented on DAEMON-336: [~stevehHexagon] thanks for the additional analysis. I'm generally supportive of enhancements to make Daemon more robust. Since this is a separate issue, please create a new enhancement request along with the sample code to reproduce the issue and a link to the PR and I'll try and take a look next time I do a Daemon release. I do want to see if there is an opportunity to catch the specific issue (possibly earlier) and report a suitable error message in addition to avoiding the crash. > prunsrv crash on service stop > - > > Key: DAEMON-336 > URL: https://issues.apache.org/jira/browse/DAEMON-336 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Windows 8.1 with Java 8 64bit, Java mode >Reporter: Volker Berlin >Priority: Major > > If the service should be stop then it crash. In the event log you can see: > Name der fehlerhaften Anwendung: foo-serverService.exe, Version: 1.0.15.0, > Zeitstempel: 0x51543b9d > Name des fehlerhaften Moduls: ntdll.dll, Version: 6.3.9600.17736, > Zeitstempel: 0x550f4336 > Ausnahmecode: 0xc005 > Fehleroffset: 0x00035150 > ID des fehlerhaften Prozesses: 0x1578 > Startzeit der fehlerhaften Anwendung: 0x01d0be119603c23f > Pfad der fehlerhaften Anwendung: C:\Program Files\foo > Server\foo-serverService.exe > Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\ntdll.dll > Berichtskennung: da5b2537-2a04-11e5-8063-7427ea3e8675 > Vollständiger Name des fehlerhaften Pakets: > Anwendungs-ID, die relativ zum fehlerhaften Paket ist: -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DAEMON-336) prunsrv crash on service stop
[ https://issues.apache.org/jira/browse/DAEMON-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17407185#comment-17407185 ] Mark Thomas commented on DAEMON-336: I have made a comment on the detail of the patch but I'd like to see the steps to reproduce this with 1.2.4 before applying the patch as I am not currently convinced it is necessary with the 1.2.4 code. > prunsrv crash on service stop > - > > Key: DAEMON-336 > URL: https://issues.apache.org/jira/browse/DAEMON-336 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.0.15 > Environment: Windows 8.1 with Java 8 64bit, Java mode >Reporter: Volker Berlin >Priority: Major > > If the service should be stop then it crash. In the event log you can see: > Name der fehlerhaften Anwendung: foo-serverService.exe, Version: 1.0.15.0, > Zeitstempel: 0x51543b9d > Name des fehlerhaften Moduls: ntdll.dll, Version: 6.3.9600.17736, > Zeitstempel: 0x550f4336 > Ausnahmecode: 0xc005 > Fehleroffset: 0x00035150 > ID des fehlerhaften Prozesses: 0x1578 > Startzeit der fehlerhaften Anwendung: 0x01d0be119603c23f > Pfad der fehlerhaften Anwendung: C:\Program Files\foo > Server\foo-serverService.exe > Pfad des fehlerhaften Moduls: C:\WINDOWS\SYSTEM32\ntdll.dll > Berichtskennung: da5b2537-2a04-11e5-8063-7427ea3e8675 > Vollständiger Name des fehlerhaften Pakets: > Anwendungs-ID, die relativ zum fehlerhaften Paket ist: -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DAEMON-411) Services can't be installed as Type=Interactive anymore
[
https://issues.apache.org/jira/browse/DAEMON-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17390470#comment-17390470
]
Mark Thomas commented on DAEMON-411:
The Tomcat Installer for Windows was updated at the same time as the switch to
Daemon 1.2.0 to set the correct permissions. See
[https://github.com/apache/tomcat/commit/e110331129]
It appears that the installer you are using hasn't made the same update.
> Services can't be installed as Type=Interactive anymore
> ---
>
> Key: DAEMON-411
> URL: https://issues.apache.org/jira/browse/DAEMON-411
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.2.0
> Environment: openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (Zulu 8.40.0.25-CA-win64) (build 1.8.0_222-b10)
> OpenJDK 64-Bit Server VM (Zulu 8.40.0.25-CA-win64) (build 25.222-b10, mixed
> mode)
> Tested on Windows 10 1607 and Windows 7 7601.
>Reporter: Markus Adelsberger
>Priority: Major
> Labels: windows
> Fix For: 1.2.3
>
> Attachments: prunsrv.png
>
>
> Installing a service with the parameter --Type=interactive no longer works.
> prunsrv.exe outputs:
> {code:java}
> prunsrv.exe //IS//MyService
> --Install="C:\service\commons-daemon-1.2.2-bin\windows\amd64\prunsrv.exe"
> --Type=interactive --ServiceUser="LocalSystem"
> The parameter is incorrect.
> Failed to install service.{code}
> No other log is output, even with Debug level. As a workaround the service
> can be installed without the type interactive and then updated to use the
> flag.
> The same call still worked in 1.1.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DAEMON-411) Services can't be installed as Type=Interactive anymore
[
https://issues.apache.org/jira/browse/DAEMON-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17390455#comment-17390455
]
Mark Thomas commented on DAEMON-411:
Breaks which version of Tomcat, on which version of Windows, how? I haven't
noticed any issues in my local testing. Also this patch has been in place for
2+ years and I don't recall Tomcat users reporting this as an issue.
I would very strongly against changing the default user back to LocalSystem
because of the security implications.
> Services can't be installed as Type=Interactive anymore
> ---
>
> Key: DAEMON-411
> URL: https://issues.apache.org/jira/browse/DAEMON-411
> Project: Commons Daemon
> Issue Type: Bug
> Components: Procrun
>Affects Versions: 1.2.0
> Environment: openjdk version "1.8.0_222"
> OpenJDK Runtime Environment (Zulu 8.40.0.25-CA-win64) (build 1.8.0_222-b10)
> OpenJDK 64-Bit Server VM (Zulu 8.40.0.25-CA-win64) (build 25.222-b10, mixed
> mode)
> Tested on Windows 10 1607 and Windows 7 7601.
>Reporter: Markus Adelsberger
>Priority: Major
> Labels: windows
> Fix For: 1.2.3
>
> Attachments: prunsrv.png
>
>
> Installing a service with the parameter --Type=interactive no longer works.
> prunsrv.exe outputs:
> {code:java}
> prunsrv.exe //IS//MyService
> --Install="C:\service\commons-daemon-1.2.2-bin\windows\amd64\prunsrv.exe"
> --Type=interactive --ServiceUser="LocalSystem"
> The parameter is incorrect.
> Failed to install service.{code}
> No other log is output, even with Debug level. As a workaround the service
> can be installed without the type interactive and then updated to use the
> flag.
> The same call still worked in 1.1.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DAEMON-432) StopTimeout flag not applied when using ProcRun
[ https://issues.apache.org/jira/browse/DAEMON-432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-432. Resolution: Duplicate > StopTimeout flag not applied when using ProcRun > --- > > Key: DAEMON-432 > URL: https://issues.apache.org/jira/browse/DAEMON-432 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.2.3 > Environment: Windows 2019 x64 >Reporter: Japie vd Linde >Priority: Major > Fix For: 1.2.5 > > > Problem steps > * Create a service using Apache Commons Daemon (include 'StopTimeout=30') as > parameter when installing the service with PRUNSRV > * Let the service class have a Thread that never closes properly > * Shut down service > Observe that the service cannot be stopped and waits indefinitely, until > prunsrv.exe is killed using Task Manager. > Could this please be improved in the next version of Apache Commons Daemon? > This problem does not help where applications may require forceful exit, due > to coding bugs, making the service experience degraded as closing the service > never times out. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DAEMON-433) support native memory tracking in jsvc
[
https://issues.apache.org/jira/browse/DAEMON-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-433.
Resolution: Duplicate
The fix for DAEMON-412 fixed this for both procrun and jsvc.
> support native memory tracking in jsvc
> --
>
> Key: DAEMON-433
> URL: https://issues.apache.org/jira/browse/DAEMON-433
> Project: Commons Daemon
> Issue Type: New Feature
>Reporter: Clément Guillaume
>Priority: Major
>
> the {{XX:NativeMemoryTracking}} option needs to be set in a particular way to
> work (otherwise you get the error "Native Memory Tracking did not setup
> properly, using wrong launcher?")
> there has been few email threads about this
> https://lists.apache.org/thread.html/80ced30c47c1bceb4ef4e35b7ddc812b54b3079d4aa426ac73838f4f%40%3Cusers.tomcat.apache.org%3E
> https://lists.apache.org/thread.html/2a90b1b1c9a8309b92576507464f953d8f5ba6d49183fc700e8f1060%40%3Cuser.commons.apache.org%3E
> and I believe support has been added for windows procrun DAEMON-412
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (POOL-394) GenericKeyedObjectPool doesn't have getKeys() implemented
[ https://issues.apache.org/jira/browse/POOL-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17315327#comment-17315327 ] Mark Thomas commented on POOL-394: -- What are the use cases for getKeys() ? > GenericKeyedObjectPool doesn't have getKeys() implemented > - > > Key: POOL-394 > URL: https://issues.apache.org/jira/browse/POOL-394 > Project: Commons Pool > Issue Type: Bug >Affects Versions: 2.4.2 >Reporter: Vamsi Pavan Kumar Sanka >Priority: Major > > getKeys() not really implemented as specified here: > [https://commons.apache.org/proper/commons-pool2/apidocs/org/apache/commons/pool2/impl/GenericKeyedObjectPool.html#getKeys(]) > This API is needed in various scenarios. Current Jira is to expose this API. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DAEMON-429) prunsrv.exe, and prunmgr.exe improper binary protection
[ https://issues.apache.org/jira/browse/DAEMON-429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17273084#comment-17273084 ] Mark Thomas commented on DAEMON-429: It is likely that this will get resolved as WONTFIX. Commons Daemon release builds jump through a bunch of hoops to make sure that the resulting binaries will work on a clean install of any currently supported version of Windows. We do not wish it to be a requirement to install one of the Microsoft Visual Studio run-times in order for Commons Daemon to work. In short, we use a tool-chain based in Visual Studio 2008 as that is the latest version of Visual Studio that will create binaries without additional dependencies. Control Flow Guard requires at least Visual Studio 15. I'll do some tests but I am all but certain that this would then require the installation of an additional runtime. If we can limit the dependencies to the UCRT then once Windows 8.1 is out of support (another 2 years) then we'll be able to switch to a newer version of Visual Studio since Windows 10 onwards includes UCRT. I'll also note that we provide source and you are, of course, free to build your own binaries with any version of Visual Studio and any additional compilation options you wish. > prunsrv.exe, and prunmgr.exe improper binary protection > --- > > Key: DAEMON-429 > URL: https://issues.apache.org/jira/browse/DAEMON-429 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun, prunsrv >Affects Versions: 1.2.3 >Reporter: Sambasivarao Garidi >Priority: Critical > > The PESecurity utility identified the specified (prunsrv.exe, and > prunmgr.exe) does not have Control Flow Guard enabled causing it to fail our > software security check. We would like to request that these (prunsrv.exe, > and prunmgr.exe) to be compiled with the Control Flow Guard enabled in the > next Apache commons-daemon release. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DAEMON-426) CAP_DAC_READ_SEARCH not allowed in containers by default
[
https://issues.apache.org/jira/browse/DAEMON-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-426.
Fix Version/s: 1.2.4
Resolution: Fixed
No response from original reporter. Assuming the proposed fix is sufficient.
> CAP_DAC_READ_SEARCH not allowed in containers by default
>
>
> Key: DAEMON-426
> URL: https://issues.apache.org/jira/browse/DAEMON-426
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.2.2
> Environment: Redhat 7; jsvc 1.2.3
>Reporter: Sheridan Rawlins
>Priority: Major
> Fix For: 1.2.4
>
>
> jsvc tries to get {{CAP_DAC_READ_SEARCH}} capabilities. The code says [Fix
> DAEMON-16 by adding CAP_DAC_READ_SEARCH to allow reading
> /proc/self|https://github.com/apache/commons-daemon/commit/2090bd1586f30f4a72ab192df6b7e7f9f5548922#diff-71c2181bdc541da57b93eb9c43851baa9457ca97e6cf1e9f8ee1c280d273ca5a]
> but does anyone still need this? It fails on docker containers in kubernetes
> unless admins allow that capability to be requested.
> I tried compiling it without this flag and it seems to run everything just
> fine - but to not break anyone who might really need this CAP, perhaps some
> command line switch could be added to adjust what capabilities are requested
> generally, or at the very least specifically whether to not alter that
> CAP_DAC_READ_SEARCH cap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DAEMON-428) apxMultiSzToArrayW has incorrect use of IS_INVALID_HANDLE
[ https://issues.apache.org/jira/browse/DAEMON-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-428. Fix Version/s: 1.2.4 Resolution: Fixed > apxMultiSzToArrayW has incorrect use of IS_INVALID_HANDLE > -- > > Key: DAEMON-428 > URL: https://issues.apache.org/jira/browse/DAEMON-428 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.0.8 >Reporter: Paul Smith >Priority: Major > Fix For: 1.2.4 > > Attachments: prunsrv.patch > > > The same issue as reported in DAEMON-163 is also present in the > apxMultiSzToArrayW() method in src/native/windows/src/utils.c. > Patch to fix is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DAEMON-428) apxMultiSzToArrayW has incorrect use of IS_INVALID_HANDLE
[ https://issues.apache.org/jira/browse/DAEMON-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259582#comment-17259582 ] Mark Thomas commented on DAEMON-428: Thanks for the report. A search of the code base found a second instance just above the one you reported in apxSetEnvironmentVariable. I have a fix fro both and should be committing it shortly. > apxMultiSzToArrayW has incorrect use of IS_INVALID_HANDLE > -- > > Key: DAEMON-428 > URL: https://issues.apache.org/jira/browse/DAEMON-428 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.0.8 >Reporter: Paul Smith >Priority: Major > Attachments: prunsrv.patch > > > The same issue as reported in DAEMON-163 is also present in the > apxMultiSzToArrayW() method in src/native/windows/src/utils.c. > Patch to fix is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DAEMON-427) Lack of JvmOptions causes crash
[ https://issues.apache.org/jira/browse/DAEMON-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-427. Resolution: Duplicate > Lack of JvmOptions causes crash > --- > > Key: DAEMON-427 > URL: https://issues.apache.org/jira/browse/DAEMON-427 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.2.3 >Reporter: Grzegorz Niemirowski >Priority: Major > Labels: documentation > > When --JvmOptions parameter is not specified, a NULL pointer is passed to > setInprocEnvironmentOptions(). The function doesn't check for NULL pointer > and tries to dereference it. > From the documentation I guess JvmOptions is not a mandatory parameter. It > says the parameter has default value and the parameter is not mentioned in > the install example. prunsrv should work without this parameter. Now it > crashes and Windows returns an error: _Error 1067_: The process terminated > unexpectedly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (DAEMON-428) apxMultiSzToArrayW has incorrect use of IS_INVALID_HANDLE
[ https://issues.apache.org/jira/browse/DAEMON-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas reopened DAEMON-428: > apxMultiSzToArrayW has incorrect use of IS_INVALID_HANDLE > -- > > Key: DAEMON-428 > URL: https://issues.apache.org/jira/browse/DAEMON-428 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.0.8 >Reporter: Paul Smith >Priority: Major > Attachments: prunsrv.patch > > > The same issue as reported in DAEMON-163 is also present in the > apxMultiSzToArrayW() method in src/native/windows/src/utils.c. > Patch to fix is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DAEMON-428) apxMultiSzToArrayW has incorrect use of IS_INVALID_HANDLE
[ https://issues.apache.org/jira/browse/DAEMON-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-428. Resolution: Duplicate > apxMultiSzToArrayW has incorrect use of IS_INVALID_HANDLE > -- > > Key: DAEMON-428 > URL: https://issues.apache.org/jira/browse/DAEMON-428 > Project: Commons Daemon > Issue Type: Bug > Components: prunsrv >Affects Versions: 1.0.8 >Reporter: Paul Smith >Priority: Major > Attachments: prunsrv.patch > > > The same issue as reported in DAEMON-163 is also present in the > apxMultiSzToArrayW() method in src/native/windows/src/utils.c. > Patch to fix is attached. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DAEMON-426) CAP_DAC_READ_SEARCH not allowed in containers by default
[
https://issues.apache.org/jira/browse/DAEMON-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17245997#comment-17245997
]
Mark Thomas commented on DAEMON-426:
After some digging I think I figured out what is going on.
The -procname option is implemented using execve and that needs the path to the
binary.
The path to the binary is obtained from /proc/self/exe falling back to argv[0]
if that fails.
CAP_DAC_READ_SEARCH is required in order to read /proc/self/exe
jsvc fails if any requested capability isn't available.
So jsvc fails on docker because CAP_DAC_READ_SEARCH isn't available.
Commenting out CAP_DAC_READ_SEARCH causes the read of /proc/self/exe to fail so
jsvc falls back to argv[0] which works.
I've re-worked the capability code to try and request CAP_DAC_READ_SEARCH but
to fall back to trying without that capability if the initial request fails.
If you could test the current code that would be very helpful.
> CAP_DAC_READ_SEARCH not allowed in containers by default
>
>
> Key: DAEMON-426
> URL: https://issues.apache.org/jira/browse/DAEMON-426
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.2.2
> Environment: Redhat 7; jsvc 1.2.3
>Reporter: Sheridan Rawlins
>Priority: Major
>
> jsvc tries to get {{CAP_DAC_READ_SEARCH}} capabilities. The code says [Fix
> DAEMON-16 by adding CAP_DAC_READ_SEARCH to allow reading
> /proc/self|https://github.com/apache/commons-daemon/commit/2090bd1586f30f4a72ab192df6b7e7f9f5548922#diff-71c2181bdc541da57b93eb9c43851baa9457ca97e6cf1e9f8ee1c280d273ca5a]
> but does anyone still need this? It fails on docker containers in kubernetes
> unless admins allow that capability to be requested.
> I tried compiling it without this flag and it seems to run everything just
> fine - but to not break anyone who might really need this CAP, perhaps some
> command line switch could be added to adjust what capabilities are requested
> generally, or at the very least specifically whether to not alter that
> CAP_DAC_READ_SEARCH cap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (DAEMON-426) CAP_DAC_READ_SEARCH not allowed in containers by default
[
https://issues.apache.org/jira/browse/DAEMON-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243002#comment-17243002
]
Mark Thomas commented on DAEMON-426:
A quick look at the source suggests that that capability is required. It may be
we can move the logic around to not request the capability when it is not
required. The full command line used by the OP to call jsvc in the docker
container would be helpful.
As an aside, it also looks like there is some code for compatibility with very
old Linux kernels that we could remove now.
> CAP_DAC_READ_SEARCH not allowed in containers by default
>
>
> Key: DAEMON-426
> URL: https://issues.apache.org/jira/browse/DAEMON-426
> Project: Commons Daemon
> Issue Type: Bug
> Components: Jsvc
>Affects Versions: 1.2.2
> Environment: Redhat 7; jsvc 1.2.3
>Reporter: Sheridan Rawlins
>Priority: Major
>
> jsvc tries to get {{CAP_DAC_READ_SEARCH}} capabilities. The code says [Fix
> DAEMON-16 by adding CAP_DAC_READ_SEARCH to allow reading
> /proc/self|https://github.com/apache/commons-daemon/commit/2090bd1586f30f4a72ab192df6b7e7f9f5548922#diff-71c2181bdc541da57b93eb9c43851baa9457ca97e6cf1e9f8ee1c280d273ca5a]
> but does anyone still need this? It fails on docker containers in kubernetes
> unless admins allow that capability to be requested.
> I tried compiling it without this flag and it seems to run everything just
> fine - but to not break anyone who might really need this CAP, perhaps some
> command line switch could be added to adjust what capabilities are requested
> generally, or at the very least specifically whether to not alter that
> CAP_DAC_READ_SEARCH cap.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Deleted] (FILEUPLOAD-308) Reasons To Fall In Love With Studying Online
[ https://issues.apache.org/jira/browse/FILEUPLOAD-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas deleted FILEUPLOAD-308: --- > Reasons To Fall In Love With Studying Online > > > Key: FILEUPLOAD-308 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-308 > Project: Commons FileUpload > Issue Type: Bug >Reporter: Amber bolton >Priority: Major > > More than 6 million students in the US [study > online|https://myhomeworkwriter.com/]. Online learning began as early as the > late ’80s, and since then, the number of online students increases year after > year. However, it wasn’t until the March 2020 COVID-19 crisis that the world > paid more attention to e-learning. Online education platforms have since seen > a spike in user numbers as educational institutions are forced to turn to > e-learning due to the lockdown. > With the many advantages that online learning offers, there is no turning > back from it. Here are reasons to fall in love with studying online. > *Manageability* > Online classes seamlessly weave into day-to-day activities. This is > particularly significant for professionals who juggle career and family > duties. Research has proved that 60% of online learners are professionals > seeking career advancement, promotions, or daring to switch careers entirely. > Learning in the comfort of their home [saves the learners time and > trouble|https://customwritingbee.com/]. Online learning also allows learners > to take extra courses because they can better manage their time. > *Cost-effective.* > Since online classes are virtual, they are charged lower than physical > classes. Moreover, their virtual nature means no extra costs are incurred > when studying. There’s no traveling to school or paying for meals and > boarding fees. The only expenses incurred in online classes are tuition fees > and internet costs. E-Learning has made [education affordable and > accessible|https://tutoringprofessors.com/] to more people worldwide. > *Flexibility* > The average online student is 32 years old, and out of all the online > students, 54% take part-time courses. Online classes are very flexible > compared to in-person classes, which is why middle-aged adults love them. > Online students get to choose their learning hours and learn at their desired > pace. In-person classes are mostly inconsiderate of the learner’s different > cognitive capabilities. Therefore, slow students never get to catch up with > the average and bright students. Students determine the progress of their > online classes. Online courses are easier to schedule around the learner’s > lifestyle. > *Accessibility* > With [online learning|https://gradewriters.com/], the location of student and > instructor means nothing. E-learning has made it possible for learners to > take courses offered anywhere in the world. > Learners are spoilt for choice in online education. A learner only needs an > internet-connected device to access any course they desire. Some universities > offer complete online undergraduate courses, allowing learners the > opportunity to earn degrees in their homes. Many graduates have acquired a > second degree through an online course. > *Lower Student To Instructor Ratio.* > A lecture hall holding 300 students is a likely scenario in traditional > in-person lectures. However, with online classes, these numbers can go as low > as 25 students in a class. It reduces the burden on the instructors and > minimizes the gap between instructor and student. Based on this, it is easy > to see why students might get more out of virtual classes than in-person > lectures. Since everything is done online, students can efficiently work with > their instructors for better performance. > *Comfort* > Is there anything more comfortable than studying at home? Online learning > lets students decide where to study. Learners have the luxury of learning in > their houses, at restaurants, in a library, etc. The convenience is > remarkable. > *Better Assessment Methods* > Most online courses do not include exams. Instead, assignments and tasks are > used to assess the learner’s progress. This approach feels better for most > learners. With no exam pressure, online students can relax and thus learn > better. > *Motivation* > Online learning opens up opportunities and inspiration. Most people want to > learn, but they do not want to be in class. The convenience and flexibility > of online courses motivate some people to study and even form a studying > habit. Online learning has made education seem easier and less daunting. > > *Taking Full Responsibility* > Students taking online classes are entirely in charge of their education. > While this freedom might be destructive to some
[jira] [Resolved] (DAEMON-424) stderr logfile is corrupted when running Tomcat 8.5 as Windows service
[
https://issues.apache.org/jira/browse/DAEMON-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-424.
Fix Version/s: 1.2.4
Resolution: Fixed
Thanks for the analysis and for the patch. The fix will be in the next release.
> stderr logfile is corrupted when running Tomcat 8.5 as Windows service
> --
>
> Key: DAEMON-424
> URL: https://issues.apache.org/jira/browse/DAEMON-424
> Project: Commons Daemon
> Issue Type: Bug
> Components: prunsrv
>Affects Versions: 1.2.3
> Environment: * Windows 10 Version 1909
> * Apache Tomcat 8.5.59
> * Adopt OpenJDK 1.8.0_222
>Reporter: Bernhard Scholz
>Priority: Major
> Fix For: 1.2.4
>
> Attachments: DAEMON-424_scholzb-hb.patch,
> uncaught-exception-sample.zip
>
>
> _Note: This issue has originally been reported under
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64863 for the Tomcat 8
> project._
> h3. Description
> When Tomcat is running as a Windows Service, output written to System.err may
> be overwritten again in the tomcat8-stderr*.log file.
> This includes messages about uncaught exceptions. As a consequence, the
> occurrence of an uncaught exception may remain undetected since it appears in
> no log file.
> h3. Steps to reproduce
> # Install Tomcat as a Windows Service with default settings
> # Build attached Maven project [^uncaught-exception-sample.zip] and deploy
> WAR file into Tomcat
> # Restart Tomcat
> # Inspect file logs/tomcat8-stderr-.log every few seconds
> h3. Expected behavior
> When startup is finished, the file should contain:
> {noformat}
> 30-Oct-2020 14:46:12.669 INFORMATION [main]
> org.apache.catalina.core.StandardEngine.startInternal Starting Servlet
> Engine: Apache Tomcat/8.5.59
> 30-Oct-2020 14:46:12.810 INFORMATION [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployWAR Deploying web application
> archive [C:\Program Files\Apache Software Foundation\Tomcat
> 8.5\webapps\uncaught-exception-sample-1.0-SNAPSHOT.war]
> Message 0 from localhost-start-stop thread
> Message 1 from localhost-start-stop thread
> Message 2 from localhost-start-stop thread
> Message 3 from localhost-start-stop thread
> Message 4 from localhost-start-stop thread
> Message 5 from localhost-start-stop thread
> Message 6 from localhost-start-stop thread
> Message 7 from localhost-start-stop thread
> Message 8 from localhost-start-stop thread
> Message 9 from localhost-start-stop thread
> Exception in thread "Thread-4" java.lang.RuntimeException: exception thrown
> from temporary thread
> at
> org.example.ContextLoaderListener.lambda$contextInitialized$0(ContextLoaderListener.java:17)
> at java.lang.Thread.run(Thread.java:748)
> Message 10 from localhost-start-stop thread
> Message 11 from localhost-start-stop thread
> Message 12 from localhost-start-stop thread
> Message 13 from localhost-start-stop thread
> Message 14 from localhost-start-stop thread
> Message 15 from localhost-start-stop thread
> Message 16 from localhost-start-stop thread
> Message 17 from localhost-start-stop thread
> Message 18 from localhost-start-stop thread
> Message 19 from localhost-start-stop thread
> 30-Oct-2020 14:47:01.449 INFORMATION [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
> application archive [C:\Program Files\Apache Software Foundation\Tomcat
> 8.5\webapps\uncaught-exception-sample-1.0-SNAPSHOT.war] has finished in
> [48.637] ms
> ...
> {noformat}
> h3. Actual behavior
> The custom messages and the uncaught exception message are written to the
> file and remain there for five seconds, then they are overwritten by
> subsequent log messages. When startup is finished, the file contains:
> {noformat}
> 30-Oct-2020 14:46:12.669 INFORMATION [main]
> org.apache.catalina.core.StandardEngine.startInternal Starting Servlet
> Engine: Apache Tomcat/8.5.59
> 30-Oct-2020 14:46:12.810 INFORMATION [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployWAR Deploying web application
> archive [C:\Program Files\Apache Software Foundation\Tomcat
> 8.5\webapps\uncaught-exception-sample-1.0-SNAPSHOT.war]
> 30-Oct-2020 14:47:01.449 INFORMATION [localhost-startStop-1]
> org.apache.catalina.startup.HostConfig.deployWAR Deployment of web
> application archive [C:\Program Files\Apache Software Foundation\Tomcat
> 8.5\webapps\uncaught-exception-sample-1.0-SNAPSHOT.war] has finished in
> [48.637] ms
> ...
> {noformat}
> The message about the uncaught exception is gone.
> h3. Root Cause
> _(as far as I can tell)_
> The file is opened twice during startup (by the prunsrv), and both file
> descriptors are being used in the Java application.
> Startup sequence:
> # In prunsrv.c, redirectStdStreams():
>
[jira] [Resolved] (DAEMON-425) Crash if Java Options parameter is missing
[ https://issues.apache.org/jira/browse/DAEMON-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-425. Fix Version/s: 1.2.4 Resolution: Fixed Thanks for the report. This has been fixed for the next release. > Crash if Java Options parameter is missing > -- > > Key: DAEMON-425 > URL: https://issues.apache.org/jira/browse/DAEMON-425 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun >Affects Versions: 1.2.3 > Environment: Windows 10 (16xx, 1809, 2004), Windows Server 2016, 2019 >Reporter: Rainer Schnitker >Priority: Major > Fix For: 1.2.4 > > Attachments: screenshot.png > > > Earlier versions of procrun will start without the parameter "Java/Options" > in the registry (see example). With "Options" prunsrv will start, without it > crashes. > Our setup (WiX based) should not create the registry key "Options", only the > user should add some values here. We dont want to override the old value. > > Example (with Options): > [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Apache Software Foundation\Procrun > 2.0\MyService\Parameters\Java] > "Classpath"="d:\\MyService\\lib\\*" > "Jvm"="d:\\MyService\\jre\\bin\\server\\jvm.dll" > "JvmMx"=dword:0800 > "Options"=hex(7):2d,00,44,00,6b,00,65,00,79,00,3d,00,76,00,61,00,6c,00,75,00,\ > 65,00,00,00,00,00 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DAEMON-422) Add "dump configuration" mode of operation which generates a .BAT file capabile of re-creating the dumped service
[
https://issues.apache.org/jira/browse/DAEMON-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Thomas resolved DAEMON-422.
Fix Version/s: 1.2.3
Resolution: Fixed
New command {{print}} (alternatively {{//PS)}} added.
> Add "dump configuration" mode of operation which generates a .BAT file
> capabile of re-creating the dumped service
> -
>
> Key: DAEMON-422
> URL: https://issues.apache.org/jira/browse/DAEMON-422
> Project: Commons Daemon
> Issue Type: New Feature
> Components: Procrun
>Reporter: Christopher Schultz
>Priority: Minor
> Fix For: 1.2.3
>
>
> For background, please see
> [https://lists.apache.org/list.html?us...@tomcat.apache.org:lte=1M:%2F%2FES%2F%2Fexample]
>
> Users upgrading their Apache Tomcat or Java versions are finding that they
> have to manually copy all of their configuration to a temporary location,
> delete their Windows Service, create a replacement Windows Service, and
> re-configure everything.
> It should be possible to add another mode of operation where procrun dumps
> all the information stored in the Windows Registry for the Windows Service
> our to a .BAT file which contains all of the configuration. The file could
> then be edited and run to re-create the service with minimal effort, and
> fewer opportunities for mistakes.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (DAEMON-419) jsvc support for Java 12+ preview features with --enable-preview
[ https://issues.apache.org/jira/browse/DAEMON-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-419. Fix Version/s: 1.2.3 Resolution: Fixed Confirmed that Procrun is not affected. > jsvc support for Java 12+ preview features with --enable-preview > > > Key: DAEMON-419 > URL: https://issues.apache.org/jira/browse/DAEMON-419 > Project: Commons Daemon > Issue Type: New Feature > Components: Jsvc >Affects Versions: 1.2.2 >Reporter: Manuel Dominguez Sarmiento >Priority: Major > Fix For: 1.2.3 > > > Currently jsvc offers no way to allow running Java with 12+ preview features. > This is enabled with the --enable-preview command line flag, but jsvc does > not understand this and fails with "Invalid option --enable-preview" > See the following threads: > [https://www.mail-archive.com/users@tomcat.apache.org/msg134585.html] > [http://apache-commons.680414.n4.nabble.com/How-to-pass-the-enable-preview-tomcat-parameter-with-JSVC-td4733218.html] > > Reference for preview features: > h1. JEP 12: Preview Language and VM Features > [https://openjdk.java.net/jeps/12] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (DAEMON-412) Tomcat started as windows service does not support Java Native Memory Tracking feature probably because of improper JVM initialization by Procrun
[ https://issues.apache.org/jira/browse/DAEMON-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas resolved DAEMON-412. Fix Version/s: 1.2.3 Resolution: Fixed This has been implemented (and tested) for Procrun and jsvc. > Tomcat started as windows service does not support Java Native Memory > Tracking feature probably because of improper JVM initialization by Procrun > - > > Key: DAEMON-412 > URL: https://issues.apache.org/jira/browse/DAEMON-412 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun > Environment: Windows generally (tested on Windows Server 2012 R2 but > the problem occurs probably, like the user in the internet write, on every > Windows version) >Reporter: Artur Linhart >Priority: Major > Fix For: 1.2.3 > > > In the case the user specifies some from the the NativeMemoryTracking > parameters (see > [https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47 > > |https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47] > ) like > -XX:NativeMemoryTracking=summary > in Windows service registry, restarts the service, so the option can be seen > in the log file by the startup options (for example in Tomcat logs like > catalina.log), then the Native memory tracking is still disabled and does not > work. If you try with > jcmd VM.native_memory summary > to get the information about the native JVM memory in the tomcats JVM, the > jcmd call fails with the message > : > Native memory tracking is not enabled > and in the Tomcat's log file can be found following error message: > Java HotSpot(TM) 64-Bit Server VM warning: Native Memory Tracking did not > setup properly, using wrong launcher? > The problem seems to be in the JVM launcher Procrun, which dies not > initialize the JVM properly - as far as I have understood from this blog: > [https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher > |https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher] > The Procrun.exe has to define some environment variable before the start of > JVM, etc. to get the native memory tracking to work. > Known workaround is the start of Tomcat from the command line, but this is no > option in the productive environment, where you have to let the service run > for longer time to collect the proper result and maybe also as some different > user because of security concerns, then such option is simply out of possible > scenarios. So the Tomcat service JVM cannot be in such circumstances tracked > by NMT at all, what is the problem in the mission-critical applications. > The Procrun should be modified in the way it enables the NMT in the windows > service by the startup, by setting the environment variable > NMT_LEVEL_ to the value "detail" or "summary" (or "off" if unspecified) > in the dependency on the specified or unspecified option of > -XX:NativeMemoryTracking > like done normally by java.exe > Remark: Also change of the startup mode from "jvm" to "exe" or "java" does > not help,. then the windows service does not start at all. > See also the Tomcat bug > [https://bz.apache.org/bugzilla/show_bug.cgi?id=63922|https://bz.apache.org/bugzilla/show_bug.cgi?id=63922] > which has been qualified as invalid because the problem seems to be in is in > PROCRUN. > See also the bug [TOMEE-2738] > This will probably affect every java app handled by the Procrun Daemon, if > installed and started as Windows service, not only Tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (DAEMON-419) jsvc support for Java 12+ preview features with --enable-preview
[ https://issues.apache.org/jira/browse/DAEMON-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Thomas updated DAEMON-419: --- Comment: was deleted (was: Just to (re-)confirm (tested with latest Apache Tomcat) that NMT does work when starting in java mode. If an application doesn't start in Java mode that is a separate, unrelated issue. It is jvm mode where changes are required. I am working on this now.) > jsvc support for Java 12+ preview features with --enable-preview > > > Key: DAEMON-419 > URL: https://issues.apache.org/jira/browse/DAEMON-419 > Project: Commons Daemon > Issue Type: New Feature > Components: Jsvc >Affects Versions: 1.2.2 >Reporter: Manuel Dominguez Sarmiento >Priority: Major > > Currently jsvc offers no way to allow running Java with 12+ preview features. > This is enabled with the --enable-preview command line flag, but jsvc does > not understand this and fails with "Invalid option --enable-preview" > See the following threads: > [https://www.mail-archive.com/users@tomcat.apache.org/msg134585.html] > [http://apache-commons.680414.n4.nabble.com/How-to-pass-the-enable-preview-tomcat-parameter-with-JSVC-td4733218.html] > > Reference for preview features: > h1. JEP 12: Preview Language and VM Features > [https://openjdk.java.net/jeps/12] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DAEMON-412) Tomcat started as windows service does not support Java Native Memory Tracking feature probably because of improper JVM initialization by Procrun
[ https://issues.apache.org/jira/browse/DAEMON-412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183513#comment-17183513 ] Mark Thomas commented on DAEMON-412: Just to (re-)confirm (tested with latest Apache Tomcat) that NMT does work when starting in java mode. If an application doesn't start in Java mode that is a separate, unrelated issue. It is jvm mode where changes are required. I am working on this now. > Tomcat started as windows service does not support Java Native Memory > Tracking feature probably because of improper JVM initialization by Procrun > - > > Key: DAEMON-412 > URL: https://issues.apache.org/jira/browse/DAEMON-412 > Project: Commons Daemon > Issue Type: Bug > Components: Procrun > Environment: Windows generally (tested on Windows Server 2012 R2 but > the problem occurs probably, like the user in the internet write, on every > Windows version) >Reporter: Artur Linhart >Priority: Major > > In the case the user specifies some from the the NativeMemoryTracking > parameters (see > [https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47 > > |https://docs.oracle.com/en/java/javase/11/vm/native-memory-tracking.html#GUID-0DB3B8D1-8D7D-447F-B6FF-15620103EE47] > ) like > -XX:NativeMemoryTracking=summary > in Windows service registry, restarts the service, so the option can be seen > in the log file by the startup options (for example in Tomcat logs like > catalina.log), then the Native memory tracking is still disabled and does not > work. If you try with > jcmd VM.native_memory summary > to get the information about the native JVM memory in the tomcats JVM, the > jcmd call fails with the message > : > Native memory tracking is not enabled > and in the Tomcat's log file can be found following error message: > Java HotSpot(TM) 64-Bit Server VM warning: Native Memory Tracking did not > setup properly, using wrong launcher? > The problem seems to be in the JVM launcher Procrun, which dies not > initialize the JVM properly - as far as I have understood from this blog: > [https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher > |https://blogs.oracle.com/poonam/using-nmt-with-custom-jvm-launcher] > The Procrun.exe has to define some environment variable before the start of > JVM, etc. to get the native memory tracking to work. > Known workaround is the start of Tomcat from the command line, but this is no > option in the productive environment, where you have to let the service run > for longer time to collect the proper result and maybe also as some different > user because of security concerns, then such option is simply out of possible > scenarios. So the Tomcat service JVM cannot be in such circumstances tracked > by NMT at all, what is the problem in the mission-critical applications. > The Procrun should be modified in the way it enables the NMT in the windows > service by the startup, by setting the environment variable > NMT_LEVEL_ to the value "detail" or "summary" (or "off" if unspecified) > in the dependency on the specified or unspecified option of > -XX:NativeMemoryTracking > like done normally by java.exe > Remark: Also change of the startup mode from "jvm" to "exe" or "java" does > not help,. then the windows service does not start at all. > See also the Tomcat bug > [https://bz.apache.org/bugzilla/show_bug.cgi?id=63922|https://bz.apache.org/bugzilla/show_bug.cgi?id=63922] > which has been qualified as invalid because the problem seems to be in is in > PROCRUN. > See also the bug [TOMEE-2738] > This will probably affect every java app handled by the Procrun Daemon, if > installed and started as Windows service, not only Tomcat. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (DAEMON-419) jsvc support for Java 12+ preview features with --enable-preview
[ https://issues.apache.org/jira/browse/DAEMON-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17183494#comment-17183494 ] Mark Thomas commented on DAEMON-419: Just to (re-)confirm (tested with latest Apache Tomcat) that NMT does work when starting in java mode. If an application doesn't start in Java mode that is a separate, unrelated issue. It is jvm mode where changes are required. I am working on this now. > jsvc support for Java 12+ preview features with --enable-preview > > > Key: DAEMON-419 > URL: https://issues.apache.org/jira/browse/DAEMON-419 > Project: Commons Daemon > Issue Type: New Feature > Components: Jsvc >Affects Versions: 1.2.2 >Reporter: Manuel Dominguez Sarmiento >Priority: Major > > Currently jsvc offers no way to allow running Java with 12+ preview features. > This is enabled with the --enable-preview command line flag, but jsvc does > not understand this and fails with "Invalid option --enable-preview" > See the following threads: > [https://www.mail-archive.com/users@tomcat.apache.org/msg134585.html] > [http://apache-commons.680414.n4.nabble.com/How-to-pass-the-enable-preview-tomcat-parameter-with-JSVC-td4733218.html] > > Reference for preview features: > h1. JEP 12: Preview Language and VM Features > [https://openjdk.java.net/jeps/12] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
