[GitHub] [commons-parent] garydgregory merged pull request #263: Bump junit-bom from 5.9.2 to 5.9.3
garydgregory merged PR #263: URL: https://github.com/apache/commons-parent/pull/263 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-parent] garydgregory merged pull request #265: Bump jacoco-maven-plugin from 0.8.9 to 0.8.10
garydgregory merged PR #265: URL: https://github.com/apache/commons-parent/pull/265 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-parent] garydgregory merged pull request #266: Bump cyclonedx-maven-plugin from 2.7.7 to 2.7.8
garydgregory merged PR #266: URL: https://github.com/apache/commons-parent/pull/266 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (IO-788) FileUtils.moveFile(File, File) can cause IOException in Windows.
[ https://issues.apache.org/jira/browse/IO-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716884#comment-17716884 ] Gary D. Gregory commented on IO-788: [~dgarratt] I plan on cutting a release candidate this week. Please validate git master as much as you can ASAP. TY! > FileUtils.moveFile(File, File) can cause IOException in Windows. > > > Key: IO-788 > URL: https://issues.apache.org/jira/browse/IO-788 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.11.0 > Environment: Windows >Reporter: Phu Dinh >Priority: Critical > > Hi, > This report is spawn from a bug found in commons-fileupload:1.4 and up. > > https://issues.apache.org/jira/browse/FILEUPLOAD-338 > > The code at this line: > [https://github.com/apache/commons-io/blob/f22a4227401855ecbfdf8184bbe37275c3aeb5c3/src/main/java/org/apache/commons/io/FileUtils.java#L2392] > > can cause IOException when the .tmp file is deleted during the writing the > upload file to disk. > We found that the java process holding on to the open handler of the .tmp > file (during the read for writing to the destination file); thus the delete() > operation fails and the IOException is thrown. > > This problem only happens on Windows. > > Thanks, -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IO-788) FileUtils.moveFile(File, File) can cause IOException in Windows.
[ https://issues.apache.org/jira/browse/IO-788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17716876#comment-17716876 ] David Garratt commented on IO-788: -- Hi [~ggregory] - any news on thr 2.12.0 release ? > FileUtils.moveFile(File, File) can cause IOException in Windows. > > > Key: IO-788 > URL: https://issues.apache.org/jira/browse/IO-788 > Project: Commons IO > Issue Type: Bug > Components: Utilities >Affects Versions: 2.11.0 > Environment: Windows >Reporter: Phu Dinh >Priority: Critical > > Hi, > This report is spawn from a bug found in commons-fileupload:1.4 and up. > > https://issues.apache.org/jira/browse/FILEUPLOAD-338 > > The code at this line: > [https://github.com/apache/commons-io/blob/f22a4227401855ecbfdf8184bbe37275c3aeb5c3/src/main/java/org/apache/commons/io/FileUtils.java#L2392] > > can cause IOException when the .tmp file is deleted during the writing the > upload file to disk. > We found that the java process holding on to the open handler of the .tmp > file (during the read for writing to the destination file); thus the delete() > operation fails and the IOException is thrown. > > This problem only happens on Windows. > > Thanks, -- 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)
