[
https://issues.apache.org/jira/browse/DAEMON-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17717239#comment-17717239
]
Klaus Malorny edited comment on DAEMON-459 at 4/27/23 2:49 PM:
---------------------------------------------------------------
As an attachment to this issue, I have added a small test program to reproduce
the effect. It contains both the source code and the compiled classes. Go the
the "app" directory and start it as follows:
{color:#000000}jsvc -debug -cp "build/install/app/lib/*" -cwd `pwd` -pidfile
/tmp/jsvc.pid Main{color}
After 5 seconds, the app tries to restart itself. It only succeeds once. If
anything is still unclear, please let me know.
was (Author: JIRAUSER299952):
As an attachment to this issue, I have added a small test program to reproduce
the effect. It contains both the source code and the compile classes. Go the
the "app" directory and start it as follows:
{color:#000000}jsvc -debug -cp "build/install/app/lib/*" -cwd `pwd` -pidfile
/tmp/jsvc.pid Main{color}
After 5 seconds, the app tries to restart itself. It only succeeds once. If
anything is still unclear, please let me know.
> 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
> 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(&act, '\0', sizeof(act));}}
> {{ act.sa_handler = handler;}}
> {{ sigemptyset(&act.sa_mask);}}
> {{ act.sa_flags = SA_RESTART | SA_NOCLDSTOP;}}
> {{ sigaction(SIGHUP, &act, NULL);}}
> {{ sigaction(SIGUSR1, &act, NULL);}}
> {{ sigaction(SIGUSR2, &act, NULL);}}
> {{ sigaction(SIGTERM, &act, NULL);}}
> {{ sigaction(SIGINT, &act, 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)
