Executing Commands From Windows Service

[David Bolen]

David Bolen <db3l.net at gmail.com> writes:

> Not from my past experience - the system account (LocalSystem for
> services) can be surprising, in that it's pretty much unlimited access
> to all local resources, but severely limited in a handful of cases,
> one of which is any attempt to access the network.  I can't recall for
> sure if it's an absolute block, or if in some cases you can configure
> around it (e.g., it might use a null session for remote shares which
> can be enabled through the registry on the target machine).  I've
> basically stuck "LocalSystem = no network" in my head from past
> experience.

Given it's been a few years, I decided to try some tests, and the
above is too simplistic.

The LocalSystem account runs without any local Windows credentials
(e.g., not like a logged in user), which has several consequences.
One is that you can't access any network resources that require such
credentials (like shares).  However, there's no sort of firewall
filtering or anything, so plain old TCP/IP connections are fine.
Unless, of course, the client being used also has other needs for
local Windows credentials, independent or as a pre-requisite to the
network operations.

So backing up a bit, the TCP/IP connection that plink is making is not
inherently disabled by running under LocalSystem, but it's certainly
possible that plink is trying to identify the user under which it is
operating to perhaps identify ssh keys or other local resources it
needs to operate.  You might be able to cover this with command line
options (e.g., plink supports "-i" to specify a key file to use), but
you'll also need to ensure that the file you are referencing is
readable by the LocalSystem account.

One of the other responders had a very good point about locating plink
in the first place too.  Services run beneath an environment that is
inherited from the service control manager process, and won't include
various settings that are applied to your user when logged in,
especially things like local path changes, and working directories.
Should you change the system path (via the environment settings),
you'll need to reboot for the service control manager to notice - I
don't think you can restart it without a reboot.

So it's generally safer to be very clear, and absolute when possible,
in a service for paths to external resources.

The prior advice of running the service as an identified user (e.g.,
with local credentials) is still good as it does remove most of these
issues since if you can run the script manually under that user you
know it'll work under service.  But it's not a hard requirement.

If your script is dying such that a top level exception is being
raised you should be able to find it in the application event log.  So
that might give further information on what about the different
environment is problematic.

You can also use the win32traceutil module to help with grabbing debug
output on the fly.  Import the module in your service, which will
implicitly redirect stdout/stderr to a trace buffer.  Run the same
win32traceutil module from the command line in another window.  Then
start the service.  Any stdout/stderr will be reflected in the other
window.  Can't catch everything (suppressed exceptions, or I/O that
doesn't flow through the script's stdout/stderr), but again might help
point in the right direction.

-- David