On Feb 9, 4:25 pm, David Bolen <db3l....@gmail.com> wrote: > David Bolen <db3l....@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
Great suggestions once again - I did verify that it was at least running the plink.exe binary when under LocalSystem by having the service run "plink.exe > C:\plinkoutput.txt" - this worked fine. And, as I mentioned, it's now working just fine when running under a regular admin account. So, I think that's going to be my solution to avoid any further issues. My best guess at this point (as you mentioned), is that plink.exe is doing _something_ network-related that LocalSystem doesn't have the privileges to do - what exactly it is, I have no idea. I may play around with it some more later, but running the service under an admin account should be a perfectly acceptable solution. Also, I will be writing other Python apps that the service will be executing - so it goes without saying that I'll be including a log to file option :) Thanks again for all your guys' help! -- http://mail.python.org/mailman/listinfo/python-list
