[daemon] prunsrv x64 1.2.0 doesn't start under local service account

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[daemon] prunsrv x64 1.2.0 doesn't start under local service account

Adam Retter
After just updating from prunsrv x64 1.1.0 to 1.2.0, we are finding
that prunsrv will no longer start our service under the "local service
account".

It is very strange, as if I launch a cmd.exe as the Administrator
User, and run `prunsrv //TS/FusionDB-Server` then it starts up
correctly on the console.

However if we run `prunsrv //ES/FusionDB-Server` then we see the
following errors in service.log:

[2019-08-30 23:06:04] [info]  [ 5336] Starting service 'FusionDB-Server'...
[2019-08-30 23:06:08] [error] [ 5336] apxServiceControl(): dwState(4)
!= dwCurrentState(1); dwWin32ExitCode = 0, dwWaitHint = 0,
dwServiceSpecificExitCode = 0
[2019-08-30 23:06:08] [error] [ 5336] apxServiceControl(): returning FALSE
[2019-08-30 23:06:08] [error] [ 5336] Failed to start service 'FusionDB-Server'.
[2019-08-30 23:06:08] [info]  [ 5336] Finished starting service
'FusionDB-Server', returning 0.
[2019-08-30 23:06:08] [error] [ 5336] Apache Commons Daemon procrun
failed with exit value: 5 (failed to start service).

If however we use the Windows Service Manager to modify the service to
run under the "Local System Account" (see attached screenshot), then
after that, running `prunsrv //ES/FusionDB-Server` starts the service
correctly.

Ideally we don't want to run under the `Local System Account` we want
to use the `local service account` instead. This seemed to work well
with version 1.1.0 but is not working for us with version 1.2.0.

Thanks and please can you help us...

We are testing on Windows 10 x64.

--
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [daemon] prunsrv x64 1.2.0 doesn't start under local service account

Adam Retter
I should add that we are intentionally NOT specifying either `--User`
or `--ServiceUser` when installing the service via prunsrv x64.

On Sat, 31 Aug 2019 at 00:18, Adam Retter <[hidden email]> wrote:

>
> After just updating from prunsrv x64 1.1.0 to 1.2.0, we are finding
> that prunsrv will no longer start our service under the "local service
> account".
>
> It is very strange, as if I launch a cmd.exe as the Administrator
> User, and run `prunsrv //TS/FusionDB-Server` then it starts up
> correctly on the console.
>
> However if we run `prunsrv //ES/FusionDB-Server` then we see the
> following errors in service.log:
>
> [2019-08-30 23:06:04] [info]  [ 5336] Starting service 'FusionDB-Server'...
> [2019-08-30 23:06:08] [error] [ 5336] apxServiceControl(): dwState(4)
> != dwCurrentState(1); dwWin32ExitCode = 0, dwWaitHint = 0,
> dwServiceSpecificExitCode = 0
> [2019-08-30 23:06:08] [error] [ 5336] apxServiceControl(): returning FALSE
> [2019-08-30 23:06:08] [error] [ 5336] Failed to start service 'FusionDB-Server'.
> [2019-08-30 23:06:08] [info]  [ 5336] Finished starting service
> 'FusionDB-Server', returning 0.
> [2019-08-30 23:06:08] [error] [ 5336] Apache Commons Daemon procrun
> failed with exit value: 5 (failed to start service).
>
> If however we use the Windows Service Manager to modify the service to
> run under the "Local System Account" (see attached screenshot), then
> after that, running `prunsrv //ES/FusionDB-Server` starts the service
> correctly.
>
> Ideally we don't want to run under the `Local System Account` we want
> to use the `local service account` instead. This seemed to work well
> with version 1.1.0 but is not working for us with version 1.2.0.
>
> Thanks and please can you help us...
>
> We are testing on Windows 10 x64.
>
> --
> Adam Retter
>
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk



--
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [daemon] prunsrv x64 1.2.0 doesn't start under local service account

Adam Retter
I note in the release notes for 1.2.0 it states:

 - The default Windows service user has changed from LocalSystem to
  'NT Authority\LocalService'

Could this be the problem that I am experiencing? How can I switch
back to LocalSystem?

On Sat, 31 Aug 2019 at 00:22, Adam Retter <[hidden email]> wrote:

>
> I should add that we are intentionally NOT specifying either `--User`
> or `--ServiceUser` when installing the service via prunsrv x64.
>
> On Sat, 31 Aug 2019 at 00:18, Adam Retter <[hidden email]> wrote:
> >
> > After just updating from prunsrv x64 1.1.0 to 1.2.0, we are finding
> > that prunsrv will no longer start our service under the "local service
> > account".
> >
> > It is very strange, as if I launch a cmd.exe as the Administrator
> > User, and run `prunsrv //TS/FusionDB-Server` then it starts up
> > correctly on the console.
> >
> > However if we run `prunsrv //ES/FusionDB-Server` then we see the
> > following errors in service.log:
> >
> > [2019-08-30 23:06:04] [info]  [ 5336] Starting service 'FusionDB-Server'...
> > [2019-08-30 23:06:08] [error] [ 5336] apxServiceControl(): dwState(4)
> > != dwCurrentState(1); dwWin32ExitCode = 0, dwWaitHint = 0,
> > dwServiceSpecificExitCode = 0
> > [2019-08-30 23:06:08] [error] [ 5336] apxServiceControl(): returning FALSE
> > [2019-08-30 23:06:08] [error] [ 5336] Failed to start service 'FusionDB-Server'.
> > [2019-08-30 23:06:08] [info]  [ 5336] Finished starting service
> > 'FusionDB-Server', returning 0.
> > [2019-08-30 23:06:08] [error] [ 5336] Apache Commons Daemon procrun
> > failed with exit value: 5 (failed to start service).
> >
> > If however we use the Windows Service Manager to modify the service to
> > run under the "Local System Account" (see attached screenshot), then
> > after that, running `prunsrv //ES/FusionDB-Server` starts the service
> > correctly.
> >
> > Ideally we don't want to run under the `Local System Account` we want
> > to use the `local service account` instead. This seemed to work well
> > with version 1.1.0 but is not working for us with version 1.2.0.
> >
> > Thanks and please can you help us...
> >
> > We are testing on Windows 10 x64.
> >
> > --
> > Adam Retter
> >
> > skype: adam.retter
> > tweet: adamretter
> > http://www.adamretter.org.uk
>
>
>
> --
> Adam Retter
>
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk



--
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [daemon] prunsrv x64 1.2.0 doesn't start under local service account

Mark Thomas
On 31/08/2019 14:40, Adam Retter wrote:
> I note in the release notes for 1.2.0 it states:
>
>  - The default Windows service user has changed from LocalSystem to
>   'NT Authority\LocalService'
>
> Could this be the problem that I am experiencing? How can I switch
> back to LocalSystem?

<snip/>

>>> Ideally we don't want to run under the `Local System Account` we want
>>> to use the `local service account` instead. This seemed to work well
>>> with version 1.1.0 but is not working for us with version 1.2.0.

The above statements are contradictory.

1.1.0 uses LocalSystem by default
1.2.0 uses LocalService by default

If you want to use a different user then you are free to change via the
Windows Service Manager, prunmgr or any other available method.

If your application doesn't run under LocalService and you want it to
then you'll need to fix your application.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [daemon] prunsrv x64 1.2.0 doesn't start under local service account

Adam Retter
Hi Mark, thanks for your response. I am just wondering when you say:

> If your application doesn't run under LocalService and you want it to
> then you'll need to fix your application.

How can we diagnose why Procrun won't start our application under
LocalService? We would like to understand what it is about our
application that stops Procrun from starting it as a LocalService?

Our application installs into C:\Program Files\<our app dir>, and has
a data directory in C:\Users\<installer user>\AppData\Roaming\<our app
data dir>


--
Adam Retter

skype: adam.retter
tweet: adamretter
http://www.adamretter.org.uk

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [daemon] prunsrv x64 1.2.0 doesn't start under local service account

Mark Thomas
On 02/09/2019 09:00, Adam Retter wrote:

> Hi Mark, thanks for your response. I am just wondering when you say:
>
>> If your application doesn't run under LocalService and you want it to
>> then you'll need to fix your application.
>
> How can we diagnose why Procrun won't start our application under
> LocalService? We would like to understand what it is about our
> application that stops Procrun from starting it as a LocalService?
>
> Our application installs into C:\Program Files\<our app dir>, and has
> a data directory in C:\Users\<installer user>\AppData\Roaming\<our app
> data dir>

It is most likely a permissions issue. LocalService has a lot less
access than LocalSystem.

Review the application error logs for permissions related issues and
address them as you find them. The nature of the application may be that
it needs a dedicated (domain or local) user to run under to ensure it
gets only the permissions it needs.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]