[ https://issues.apache.org/jira/browse/DAEMON-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484656#comment-17484656 ]
Rainer Jung commented on DAEMON-437: ------------------------------------ I do like the log as an action protocol. And I do not think it would be important to make it safe for concurrent use. But: there is a conceptional problem when using configuration flags in combination with the //IS action to install a service. Those flags IMHO are getting used for the service AND also for the execution of the //IS action itself. That doesn't matter for most switches, unfortunately for the --Log* flags it dies matter. I see no way of setting the log for the //IS action different from what the service used - except for editing the service manually after the //IS execution. That's why I thought about using a different default log file name for service execution versus the interactive actions. But that still doesn't solve the conflicting uses of the --Log* flags for interactive commands versus the installed service :( > 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)