[
https://issues.apache.org/jira/browse/DAEMON-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)
