Hi there,
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 next start the installed service, 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, wther 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.
Thanks and regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
