I'm fairly new to programming and decided to setup a simple python script that would open all the applications I use for webapp development. The code I am using is (for GAE):
google_appengine = r'C:\Applications\google_app_engine\launcher\GoogleAppEngineLauncher.exe'
subprocess.Popen(google_appengine)
This works fine for the other programs I am opening, but I am unable to run any applications within App Engine after I have opened it this way. I get the following error in my App Engine log file:
Exception in thread Thread-2:
Traceback (most recent call last):
File "threading.pyc", line 486, in __bootstrap_inner
File "launcher\taskthread.pyc", line 65, in run
File "subprocess.pyc", line 587, in __init__
File "subprocess.pyc", line 700, in _get_handles
File "subprocess.pyc", line 745, in _make_inheritable
WindowsError: [Error 6] The handle is invalid
I'm guessing it is the way subprocess.Popen() works, but I haven't been able to find any alternatives. I'm running Windows 7 if that makes a difference. Thanks for looking.
if you want to manage the local dev_appserver, this is the wrong approach.
the best way to do this is clone the sdk repository (https://code.google.com/p/googleappengine/) directly to your drive and then add that path to your environment PYTHONPATH variable.
here's a link to a script template i created & often use to manage startup & killing of the dev_appserver process: https://gist.github.com/4514647
i'm not too familiar with managing a python environment on Windows, so you'd have to take my notes on a highlevel and research the specific implementation for that platform.
Related
I have a python application which is bundled using pyinstaller --onefile method. When running with multiprocessing start method spwan, it causes error in middle of the application.
Traceback (most recent call last):
File "web.py", line 1028, in <module>
File "PyInstaller/hooks/rthooks/pyi_rth_multiprocessing.py", line 49, in _freeze_support
File "multiprocessing/spawn.py", line 105, in spawn_main
File "multiprocessing/spawn.py", line 114, in _main
File "multiprocessing/spawn.py", line 225, in prepare
File "multiprocessing/spawn.py", line 277, in _fixup_main_from_path
File "runpy.py", line 261, in run_path
File "runpy.py", line 231, in _get_code_from_file
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/_MEIRtGMqX/web.py'
[11797] Failed to execute script 'web' due to unhandled exception!
start method fork seems to be fine, but sometimes it hangs due to resource lock issue, so I prefer spawn. Does any one have any idea why this error occurs?
I have been using freeze_support() as mentioned in multiprocessing documentation even though it doesn't have any impact on Linux.
if __name__ == "__main__":
freeze_support()
set_start_method('spawn')
OS - Amazon linux 2
Python - 3.6.8
PyInstaller - 4.10
As I understood about spwan, It runs a new Python interpreter whenever creates a new process and tell it to import the main module and then execute. So my main module is web.py. So the error happens when a new process is created. But this issue is not consistent.
I think the reason for this problem is that the program cannot find web.py after packaging.
You can try adding the following code where you are using about path.
if getattr(sys, 'frozen', False):
bundle_dir = sys._MEIPASS
else:
bundle_dir = os.path.dirname(os.path.abspath(__file__))
this code can help program find the file after packaging.
pyinstaller's document about this:https://pyinstaller.org/en/stable/runtime-information.html
At this point of time, Only one solution I have found is start the multiprocessing with method forkserver. I am not sure whether it leads to any hang in application.
set_start_method('forkserver')
I ran into a similar issue when processes were spawned by threads. Using the "spawn" method from pyinstaller binaries on Linux is not thread-safe. If you are spawning processes concurrently from multiple threads, this issue can arise.
Follow https://github.com/pyinstaller/pyinstaller/issues/7410 for updates.
UPDATE
Per the changelog, a fix has been released in PyInstaller 5.8.0.
I am writing a simple network scanner with python using scapy following is my code :
import scapy.all as scapy
def scan(ip):
scapy.arping(ip)
scan("192.168.1.1/24")
Error I am getting :
Traceback (most recent call last):
File "ipScanner.py", line 10, in <module>
scan("192.168.1.1/24")
File "ipScanner.py", line 8, in scan
scapy.arping(ip)
File "/Users/omairkhan/opt/anaconda3/lib/python3.7/site-packages/scapy/layers/l2.py", line 648, in arping
filter="arp and arp[7] = 2", timeout=timeout, iface_hint=net, **kargs) # noqa: E501
File "/Users/omairkhan/opt/anaconda3/lib/python3.7/site-packages/scapy/sendrecv.py", line 553, in srp
filter=filter, nofilter=nofilter, type=type)
File "/Users/omairkhan/opt/anaconda3/lib/python3.7/site-packages/scapy/arch/bpf/supersocket.py", line 242, in __init__
super(L2bpfListenSocket, self).__init__(*args, **kwargs)
File "/Users/omairkhan/opt/anaconda3/lib/python3.7/site-packages/scapy/arch/bpf/supersocket.py", line 62, in __init__
(self.ins, self.dev_bpf) = get_dev_bpf()
File "/Users/omairkhan/opt/anaconda3/lib/python3.7/site-packages/scapy/arch/bpf/core.py", line 114, in get_dev_bpf
raise Scapy_Exception("No /dev/bpf handle is available !")
scapy.error.Scapy_Exception: No /dev/bpf handle is available !
Exception ignored in: <function _L2bpfSocket.__del__ at 0x105984c20>
Traceback (most recent call last):
File "/Users/omairkhan/opt/anaconda3/lib/python3.7/site-packages/scapy/arch/bpf/supersocket.py", line 139, in __del__
self.close()
File "/Users/omairkhan/opt/anaconda3/lib/python3.7/site-packages/scapy/arch/bpf/supersocket.py", line 211, in close
if not self.closed and self.ins is not None:
AttributeError: 'L2bpfSocket' object has no attribute 'ins'
Can anyone please help understand it.
NOTE: I am running it on mac OS.
I wrote this exact program when I first started programming with matching syntax, and it ran correctly on my systems when run as administrator. I develop on Linux and Windows rather than Mac, but I will offer what I can.
Are you running this script through your IDE or calling it from the shell?
I recommend only running it from the shell. This simply gives you more control over the files like specifying which version of python the script is, and if you need administrative privileges for a script, you can elevate the script permissions in the shell.
Also, in my OS, I was taught to always use, and have experienced the mistakes of forgetting this, always add:
#!/usr/bin/env python
as the first line of every script. At least in Linux, it tells the PC how to treat the file (it tells it to treat the file as a python file--yes I acknowledge that its already running it as python). I would check to see if that is valid for MacOS file system.
Most of what I have recommended so far comes down to no /dev/bpf handle is available, only ever being an issue for me when I'm not running script as an administrator (although Linux states permission denied). And I shouldn't leave out that using Anaconda on Windows in the past (before I understood the structure of my file systems) prevented me from using common modules like pygame and scapy. I could only guess in that case Anaconda prevented the PC from knowing where to find every piece of that module by making the computer think it had its own one of that module under Anaconda directory when it was in a different PATH.
I have a requirement whereby the navigation and control of a legacy application has to be automated - this automated method, packaged as a script, would need to be deployed via SCCM to our user base.
After some research, I've decided to use Python's PywinAuto module to achieve my goal.
I've managed to create a script that automates all the GUI steps as required and I've also packaged this script as an exe using the Pyinstaller module, but the issue i'm now having is the following: when running locally on both Windows 7 and Windows 10 machines, the exe executes successful. However, when triggering the exe remotely through either SCCM or PSEXEC, the exe fails to execute.
I've also wrapped the exe in a powershell script, but the same thing occurs when executing the script via PSEXEC or SCCM.
I'm running PSEXEC as the System user, which has full admin rights. The SCCM user has full admin rights aswell.
This is the Pyinstaller example script that I packaged into an exe, just for testing purpose:
from __future__ import print_function
import logging
from pywinauto import actionlogger
from pywinauto import Application
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--log", help = "enable logging", type=str, required = False)
args = parser.parse_args()
actionlogger.enable()
logger = logging.getLogger('pywinauto')
if args.log:
logger.handlers[0] = logging.FileHandler(args.log)
app = Application(backend='uia').start(r'mspaint.exe')
dlg = app.window(title_re='.* - Paint')
dlg.close()
When running the exe locally from the the command line, the following appears indicating successful execution:
c:\Temp>pywinauto_test 2019-05-11 07:47:14,215 INFO: Started
mspaint.exe application. 2019-05-11 07:47:14,344 INFO: Closed window
"Untitled - Paint"
When running remotely through psexec, the following appears:
C:\Temp>pywinauto_test.exe 2019-05-11 07:29:38,221 INFO: Started
mspaint.exe application. [ 5516] Failed to executC:\Temp>e script
Pywinautopaint Traceback (most recent call last): File
"site-packages\pywinauto\application.py", line 256, in
__resolve_control File "site-packages\pywinauto\timings.py", line 458, in wait_until_passes pywinauto.timings.TimeoutError
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "Pywinautopaint.py", line
59, in File "site-packages\pywinauto\application.py", line
378, in getattribute File
"site-packages\pywinauto\application.py", line 259, in
__resolve_control File "site-packages\pywinauto\timings.py", line 436, in wait_until_passes File
"site-packages\pywinauto\application.py", line 201, in __get_ctrl
File "site-packages\pywinauto\findwindows.py", line 87, in
find_element pywinauto.findwindows.ElementNotFoundError: {'title_re':
'.* - Paint', 'backend': 'uia', 'process': 2844}
All known methods to run GUI automation remotely are listed in the Remote Execution Guide. It's not specific to PyInstaller or other py2exe-like tools. Mostly it's OS Windows restrictions and RDP features that can be workarounded by several ways.
Also ElementNotFoundError is often raised when default timeout to find window (5 sec.) is insufficient. For example, if remote virtual machine is slow. This might be unrelated to common remote execution problems.
I'm new to Google App Engine and I followed multiple video tutorials (One from Udacity) and for some reason I am unable to get it to run on the local host with the simple "Hello World" program.
I do have the Python SDK installed as well as the Google App Engine program installed. I did modify the YAML file so that it matches with my application (it did by default). When I click "run" in the Google App Engine launcher, it shows a yellow triangle caution sign next to the program I'm attempting to run.
When I type the localhost:8080 in the search bar it says:
This webpage is not available
I've also tried reinstalling both Python 2.7.9 and the Google App Engine and to no avail. In short I would like to understand why the program shows no content when I attempt to run it. Here are the log files if it's any help:
2015-03-14 18:36:21 Running command: "['E:\\Python\\pythonw.exe', 'C:\\Program Files (x86)\\Google\\google_appengine\\dev_appserver.py', '--skip_sdk_update_check=yes', '--port=8080', '--admin_port=8000', 'C:\\Program Files (x86)\\Google\\google_appengine\\new_project_template']"
Traceback (most recent call last):
File "C:\Program Files (x86)\Google\google_appengine\dev_appserver.py", line 83, in <module>
_run_file(__file__, globals())
File "C:\Program Files (x86)\Google\google_appengine\dev_appserver.py", line 79, in _run_file
execfile(_PATHS.script_file(script_name), globals_)
NameError: name 'execfile' is not defined
2015-03-14 18:36:21 (Process exited with code 1)
It looks like the default pythonw on your system (E:\Python\pythonw.exe) is some version of Python 3. That's where execfile is indeed not defined (and the GAE launcher's incompatible with Py3 in other ways, anyway, at this time).
To verify, run E:\Python\python.exe at a cmd prompt -- it should greet you with a version banner which I bet will mention Python 3.something.
Where did you (re-)install 2.7.9? How's your PATH environment variable? Likely with E:\Python before wherever 2.7.9 is installed.
Simplest might be to change your PATH so that wherever 2.7.9 is installed comes before E:\Python...!
So yesterday I updated to Enthought version 1.1 and now it refuses to open. I've rebooted my computer as well as did a re-install of enthought canopy. I keep getting the following error
Traceback (most recent call last):
File "build/bdist.macosx-10.5-i386/egg/canopy/app/bootstrap.py", line 1989, in main
File "build/bdist.macosx-10.5-i386/egg/canopy/app/bootstrap.py", line 1021, in main
File "build/bdist.macosx-10.5-i386/egg/canopy/app/bootstrap.py", line 1012, in _ kill_leftover_procs
File "build/bdist.macosx-10.5-i386/egg/canopy/app/running_process_manager.py", line 116, in kill_leftover_procs
File "/Applications/Canopy.app/appdata/canopy-1.1.0.1371.macosx-x86_64/Canopy.app/Contents/lib/python2.7/contextlib.py", line 17, in __enter__
return self.gen.next()
File "build/bdist.macosx-10.5-i386/egg/canopy/app/running_process_manager.py", line 59, in lock
LockError: Lock could not be acquired
I have no idea what's going on here. I've sent the error report to enthought but does anyone have any ideas?
I think I did it. Try searching for these files in your Terminal. They're inside your .canopy folder. Make sure that you're working on your root directory. They're not searchable via Finder. My Canopy's finally working now. Hope this helps.
proc_manager.lock
process.lck
running_procs.pkl
Somehow it seems like a lock file didn't get cleaned in the process. Look into the ~/.canopy folder and remove the process.lck file. You may also start your Activity Monitor and make sure there is no stray canopy or python process, and kill it if there is (or log out of OSX and log back in, which will do the same thing). Canopy will run as normally after that.