Using multiprocessing from a Windows service

Volodymyr Orlenko orlenko at gmail.com
Fri Feb 6 00:21:40 EST 2009



On 05/02/2009 8:26 PM, Mark Hammond wrote:
> On 6/02/2009 2:50 PM, Mark Hammond wrote:
>> On 6/02/2009 11:37 AM, Volodya wrote:
>>> Hi all,
>>>
>>> I think I've found a small bug with multiprocessing package on
>>> Windows.
>>
>> I'd actually argue its a bug in pythonservice.exe - it should set
>> sys.argv[] to resemble a normal python process with argv[0] being the
>> script. I'll fix it...
>
> Actually it appears I spoke too soon:
>
> * A bug in pywin32 exists such that when you use 'debug' on a service, 
> the argv reflected the full argv of the application, including the 
> '-debug' portion of the command-line.  However, even if that is fixed, 
> the next argument is actually the name of the service (as declared in 
> the .py file for the service), not the .py module itself.  Thus, I 
> could make argv a little more sane in this case, but still the initial 
> problem would remain as argv[0] would still not be a .py file.
>
> * When the service is started by windows itself, there are usually 
> zero additional command-line arguments.  If there *are* arguments, 
> they are likely to be the string the user entered via control panel as 
> a special case (Windows doesn't actually remember service args - they 
> are used once and discarded).  It is important we continue to expose 
> whatever argv we actually got from Windows to the service code.
>
> So unfortunately I don't think I can change pythonservice to resolve 
> the issue you reported.
>
Thanks Mark, this makes perfect sense.

In the patch I submitted, I simply check if the name of the supposed 
module ends with ".exe". It works fine for my case, but maybe this is 
too general. Is there a chance that a Python module would end in ".exe"? 
If so, maybe we should check specifically for "pythonservice.exe". But 
then, if someone renames the executable (as I did, because I wanted to 
see meaningful service names in the process list), the patch will not 
work. Maybe there's another way to fix the forking module?



More information about the Python-list mailing list