[python-win32] Re: Can't import wmi in scripts run by nrpe_nt

[Jan Van Uytven (Wyvern)]

Thanks Roger! That is indeed the problem, as a quick "print os.getcwd()"
proved. After I renamed wmi.py to pywmi.py, the problem vanished. Yay! I
don't understand why it would be trying to load wmi.dll. Is there a dll
import facility in Python?

Is there a way to get around this problem?

Jan
On Tue, 2004-10-26 at 16:59 -0400, Roger Upole wrote:
> Someone had a similar problem a while back:
>  
> http://mail.python.org/pipermail/python-win32/2004-May/001948.html
>  
> In that case, import was finding \system32\wmi.dll first
> and the import failed with a particularly unhelpful error
> msg.  Does the process that fails have it's current working
> directory as \system32 ?
>  
>        Roger
>  
>  
>  
> >>> I'm sorry, I could have phrased this better.
> 
> >>> BTW, I'd like to congratulate you on wmi. If it weren't so useful
> to me
> >>> I wouldn't be trying to solve this problem.
> 
> >>> Machine A is a linux box. It has Nagios installed on it. On this
> machine
> >>> is a plugin, check_nrpe, which can be called to return the result
> of a
> >>> given command on a remote box that runs the nrpe daemon, such as
> Machine
> >>> B.
> 
> >>> Machine B is a Windows 2003 server. It has Python 2.3, The Win32
> >>> extensions, and WMI installed. It has a service, nrpe_nt, which
> can
> >>> receive commands from Machine A to execute and return the results
> of any
> >>> script or executable you define.
> 
> >>> On Machine B, I have written a simple script, check_python.py,
> It's just
> >>> this:
> 
> >>> import sys,wmi
> >>> print "Imported wmi!"
> >>> sys.exit(0)
> 
> >>> On Machine B, this works fine when I run it from the command line
> >>> ("python check_python.py") or from inside PythonWin. 
> 
> >>> I have set up nrpe_nt so that when it receives the command
> >>> 'check_python' from Machine A it executes this:
> >>> "C:\Python23\python.exe C:\NRPE_NT\bin\check_python.py"
> 
> >>> However when I actually run the command the script bombs out and
> the
> >>> only reply I get from Machine B (on Machine A, where check_nrpe
> is) is
> 
> >>> tombstone libexec # ./check_nrpe -H xxx.xxx.xxx.xxx -c
> check_python
> >>> Traceback (most recent call last):
> 
> >>> After removing 'wmi' from the import list, it worked. But putting
> it
> >>> back in causes the script to bomb, and I don't know why.
> >>> These work:
> >>> * import sys,os
> >>> * import sys,os,win32com
> >>> * import sys,os,win32com,win32security
> >>> But this doesn't:
> >>> * import sys,wmi
> 
> >>> I also tried the full path version of the command manually. It
> works.
> 
> >>> So there's something different that happens when you import wmi
> from an
> >>> interactive script versus when it's called remotely by nrpe_nt.
> I've
> >>> asked the nrpe_nt dev, but he's stumped (not being a python guy).
> 
> >>> Is there something specific that happens when wmi gets imported? I
> used
> >>> the imp module, and the problem is not that the module can't be
> found,
> >>> it's that something weird happens when it gets loaded.
> 
> >>> Thanks,
> 
> >>> Jan
> 
> 
> 
> 
> _______________________________________________
> Python-win32 mailing list
> Python-win32 at python.org
> http://mail.python.org/mailman/listinfo/python-win32
---
Jan Van Uytven
Computer Systems & Network Engineer
Convergent Media Network
wyvern at crm3.com

Randomly selected from my quote-file:

"Whip me. Beat me. Make me maintain AIX."
	-paul138


>>> LEGAL STUFF <<< 
This electronic message transmission, including any attached files, 
contains information which may be confidential and/or privileged.
The information is intended to be for the SOLE use of the individual or 
entity named above. If you are not the intended recipient, be aware 
that any review, disclosure, copying, distribution or use of the 
contents of this information is prohibited. This message is not to be 
forwarded for any reason without prior consent of the sender. 

If you have received this electronic transmission in error, please 
notify the sender immediately by telephone (250) 386-4266 or by a 
'reply to sender only' message and destroy all electronic and hard 
copies of the communication, including attachments, without reading 
or saving in any manner.