Prev: ChooseFont() issues
Next: ANN: Seed7 Release 2010-02-07
From: Alf P. Steinbach on 7 Feb 2010 17:14
* T:
> On Feb 7, 4:43 pm, Sean DiZazzo <half.ital...(a)gmail.com> wrote:
>> On Feb 7, 11:02 am, T <misceveryth...(a)gmail.com> wrote:
>>
>>> I have a script, which runs as a Windows service under the LocalSystem
>>> account, that I wish to have execute some commands. Specifically, the
>>> program will call plink.exe to create a reverse SSH tunnel. Right now
>>> I'm using subprocess.Popen to do so. When I run it interactively via
>>> an admin account, all is well. However, when I'm running it via
>>> service, no luck. I'm assuming this is to do with the fact that it's
>>> trying to run under the LocalSystem account, which is failing. What
>>> would be the best way around this? Thanks!
>> Try running/debugging your service from the commandline as
>> "<servicename> debug" That should lead you to the error.
>>
>> Otherwise, we need to see a traceback and some code to be better able
>> to help.
>>
>> ~Sean
>
> It's working fine when I run it via "<servicename> debug" - that's how
> I was testing before. It's when I start the service that it fails -
> and you can see that, when you run it with debug, plink.exe runs under
> my username. When I run it as a service, it runs under System...

This sounds like a Windows programming problem, not anything related to Python
per se.

Windows services are generally limited in what they can do, such as interaction
with the user, and I guess that spills over to network access.

Also, services need to interact with the service control manager, the "scum" as
it's known. Well, all right, that's just what my coworkers and I called it once.
But essentially, it's an even-driven execution model, which means that it might
not work to use just any program, such as [python.exe], directly as a service.

The Windows Resource Kit used to have a facility for running ordinary programs
as services. I'm not sure what it did at the technical level, but it worked. Or
it appeared to work.

You might also find it useful to look up the documentation on services that
interact with the user. In the old times that was mostly a matter of configuring
which account the service ran under. But I think it all got more complicated
with Microsoft's introduction of Terminal services (generally, most of the
complication in modern Windows is due to the shift in focus about 1995, ditching
the personal computer user market in favor of the enterprise and MIS market).

Cross-posted to [comp.os.ms-windows.programmer.win32], follow-ups set to that
group -- that means, unless overridden you won't see follow-ups in [c.l.p].

I think that group may give more informative and helpful responses.


Cheers & hth.,

- Alf
 | 
Pages: 1
Prev: ChooseFont() issues
Next: ANN: Seed7 Release 2010-02-07