I was previously able to deploy an Azure function written in Python using the command func azure functionapp publish <FunctionAppName> from my project directory, building it remotely. It worked until lunchtime yesterday.
I now get the following message.
Creating archive for current directory...
Performing remote build for functions project.
Deleting the old .python_packages directory
Uploading [######################################################################################]
Remote build in progress, please wait...
Fetching changes.
Cleaning up temp folders from previous zip deployments and extracting pushed zip file /tmp/zipdeploy/c5e66350-4b87-4e72-9900-b2a1ae4521a8.zip (0.00 MB) to /tmp/zipdeploy/extracted
Central Directory corrupt.
Remote build failed!
I've tried the following to see if I can resolve it without any success:
Switching my machine off and on.
Deploying an older version of the code in case I've changed anything.
Deploying from the command prompt in visual studio code.
Reinstalling Azure functions core tools.
Deploying from a different machine on a different network (I read that there are sometimes firewall issues with uploading zip files but my IT manager assures me we have no restrictions and these settings have not been changed). In doing so, I had to install Azure functions core tools from scratch as it had never been installed on that machine before.
Creating a completely new clean functionapp and deploying there.
Creating a brand new minimal Python application in a clean directory and deploying this to the new functionapp.
I get the same message in each case.
I'm stuck here. Does anyone have any more information about what the error message might mean is going wrong or any ideas?
Other investigations -
I've tried deploying as a different Azure user (same error).
I've checked for any processes using port 9091 (none were found).
I have also tried to build locally using func azure functionapp publish IncidentProcessing4 --build local
I got some different error messages
Performing local build for functions project.
Directory .python_packages already in sync with requirements.txt. Skipping restoring dependencies...
Uploading package...
Uploading 0 B [###################################################################################]
Attempted to divide by zero.
Retry: 1 of 3
Uploading 0 B [###################################################################################]
Attempted to divide by zero.
Retry: 2 of 3
Uploading 0 B [###################################################################################]
Attempted to divide by zero.
Retry: 3 of 3
Uploading 0 B [###################################################################################]
Attempted to divide by zero.
I noticed that in my \users\name\appdata\local\temp directory 2 files had been created by the build, called temp374D.tmp and tmp374E.tmp. The first of these was 0KB in size and the 2nd 8KB in size.
My suspicion is something is causing the first file to be created and something on the server is attempting and failing to unzip it.
More additional information - "Deploy to Function App" from Visual Studio code deploys, but when the Azure function runs, I get errors about modules referenced by the function not being loaded. If it's possible to deploy the modules in requirements.txt with the function app that will be a work around.
I think I've fixed it by reverting to an earlier version of Azure Functions Core Tools. It's deploying with 2.7.1575.
I'll experiment to see if I can find out any more but I've got my function deploying now.
This may not apply, given your exhaustive set of things you did trying to diagnose the issue, but I'll throw it out there. I have run into this if my function is running, either in a terminal window (via func host start) or even via the VSCode functions extension.
It would seem like it should be obvious to see if anything's running, but I've seen VSCode leave behind function host processes in a running state. To check, you could check netstat (netstat -a -n | grep 9091) or lsof (lsof -nP -iTCP:9091 | grep LISTEN). The latter gives you the pid that has the port open.
It seems that there was a bug introduced in Azure Functions Core Tools such that if your function directory full path had a space character in it Eg- /home/my functions project/, it would create a zip package with 0 bytes.
See - https://github.com/Azure/azure-functions-core-tools/issues/1867
This will be fixed in the next release. In the meanwhile, anyone experiencing this can mitigate the problem if they switch their function project to be in a path without space characters.
Sorry about that!
I am using core-tools version 3 and the same problem exists there as well. As Ankit mentioned in his answer, the issue occurs when there's a space in the project path.
One solution to this could be to move your project to another path without spaces until the next release fixes the issue but this is not always feasible/desirable. Instead we can create a shortcut (aka junctions on windows systems) to the original folder in a new path without spaces. So here's a batch file snippet which uses junctions for publishing functions to Azure till next release.
:: login and create resources with cli
....
:: enter into a path of choice without spaces (eg. my Windows Temp folder path has no spaces)
pushd %PATH_WITHOUT_SPACES%
:: create a junction to project path here and navigate to it
mklink /J tmpdir %PROJECT_PATH_WITH_SPACES%
pushd tmpdir
:: execute publish as you would normally. It will succeed now!
call func azure functionapp publish %APP_NAME%
:: cleanup and return to old working dir
popd
rmdir tmpdir
popd
Related
I am getting the below error in the Azure Function for Python
Please see the below screenshot
Whenever I am trying to open the azure function python on the portal then I got the above error.
Let me know if anyone has any idea regarding this error.
This error can be very difficult to debug, because it seems to be caused by multiple root causes. In my case, I suspect the root cause to be a failure in pip package installation. But this is difficult to verify, because I was not able to drill in to the pip logs. The deployment log does not contain information about pip installation, and some of the logs were unavailable because the host runtime was down.
I followed these best practices to finally make the Python function deployment succeed:
Use remote build (app setting: SCM_DO_BUILD_DURING_DEPLOYMENT: 1)
Make sure that the AzureWebJobsStorage application setting is configured to point to the correct Function Storage
Do not include local .venv/ directory in deployment (add it to .funcignore)
Make sure the dependencies can be installed on the local Virtual Environment without conflicts
Test that the function runs locally without errors
In requirements.txt, I had the following lines. Note that there is no need to specify azure-functions version, since it is determined by the platform. It is only for local linting etc.
pip==21.2.*
azure-functions
As a side note, it is not necessary to specify "Build from package" (app setting: WEBSITE_RUN_FROM_PACKAGE: 1); this seems to be enabled by default.
My deployment configuration:
OS: Ubuntu 21.04
Functions Python version: 3.9
Functions Runtime Extension version: 4
Deployed with VS Code Azure extension
I have a project running on a docker container and another running on a vagrant machine, when I try in to go to definition in that two projects, I receive this message ex: "No definition found for 'BaseUserManager'. ", for all plugins that I have installed on that machines I get the same message.
PS: Go to definition just work on my local workspace.
can you guys help me to solve this problem please?, I really like vscode and I don't wanna quit the editor because of this issue.
The source has to be local for the extensions to be able to read the files to analyze the source.
I am starting the Docker tutorial with the Python app and would like to know what is the meaning of "Python runtime" in this context:
In the past, if you were to start writing a Python app, your first order of business was to install a Python runtime onto your machine. But, that creates a situation where the environment on your machine has to be just so in order for your app to run as expected; ditto for the server that runs your app.
With Docker, you can just grab a portable Python runtime as an image,
no installation necessary. Then, your build can include the base
Python image right alongside your app code, ensuring that your app,
its dependencies, and the runtime, all travel together.
So I guess what it mean is the "Python runtime" is like the configuration of your local Python.
When it says "Python runtime," it just means the Python interpreter in a binary format and its local configuration of package dependencies. Your interpretation is correct.
I need to set up a Jenkins server to build a python project. But I can't find any good tutorials online to do this, most of what I see uses pip, but our project simply works on
python.exe setup.py build
I've tried running it as a Windows Batch file setting it up through the configure options in Jenkins, where I enter the above line in the box provided, but the build fails.
When I try to run this I get a build error telling me there is no cmd file or program in my project's workspace. But it seems to me that cmd would be a program inherent to Jenkins itself in this case.
What's the best way to go about setting up Jenkins to build a python project using setup.py?
Really i used jenkins to test Java EE project and i don't khnow if it will be the same principle or not ,
so i downloaded the jenkins.war from the website and i deployed it on my jboss server and I reached it via an url on the browser : http://localhost:serverport/jenkins the i created a job and i select the server & jdk & maven & the location of my project in workspace then i make a run to build the project.
I am sorry if you find that my subject is far from your demand but I tried to give you a visibility onto my use.
I relaized I did something stupid and forgot that my coworker had set it up on a UNIX server, so I should have been using the shell instead of Windows Batch. Once I changed that and installed the python plugin, I got it to build fine.
This is an old app, running since about two years on Heroku. Now suddenly, when I deploy (standard git push), it breaks the Python interpreter, both on regular and one-off dynos. Here's what it looks like:
$ heroku run python
Running `python` attached to terminal... up, run.8338
python: error while loading shared libraries: libpython2.7.so.1.0: cannot open shared object file: No such file or directory
Further pushes, heroku restart, scaling the dynos to zero and back up, that all doesn't fix it.
The only changes contained in this deployment which I could imagine being related to this problem are: gevent upgraded from 0.13.6 to 1.0.1 and the introduction of a runtime.txt (before there was none, resulting in 2.7.4, now there's one for 2.7.6).
I rolled all of this back to no effect, however. In fact, I went back about 30 commits (the deployment contained maybe five) and pushed that and the app is still broken.
Rolling back with heroku rollback is the only way I've found to take the app back into a usable state. But of course that doesn't help me going forward.
What might cause this? Can I somehow rebuild my whole app environment from scratch?
EDIT 1: I opened a shell in a one-off dyno and I can see the libpython2.7.so.1.0 file there:
/ $ ls -la /app/.heroku/python/lib/libpython2.7.so.1.0
-r-x------ 1 u49295 49295 5694572 2014-06-03 23:39 /app/.heroku/python/lib/libpython2.7.so.1.0
Of course I don't know if that's where it's supposed to be.
Somehow certain apps did not upgrade properly. A temporary fix to locate the correct python library:
heroku config:set LD_LIBRARY_PATH=/app/.heroku/python/lib
Kenneth Reitz from the Python team here.
So, we're rolling out security updates to the version of Python that we have installed on our base system. Customers shouldn't be affected by this in any way, because their apps use their own version of Python, and because we set local runtime-specific (such as LD_LIBRARY_PATH) in a .profile.d scripts, outside of user-set configuration.
However, we allow power users to override these environment variables with $ heroku config. That's basically what the application was doing — although, not knowingly. This was an accidental side-effect of a much, much older Heroku. In older days, we couldn't have any runtime-specific configuration without being a part of user configuration. This is why your application had an LD_LIBRARY_PATH config set, and this is what caused this bug.
Because of this, I've disabled the overridability of LD_LIBRARY_PATH for Python apps, and all should be well moving forward.
Thanks for being a part of the gradual rollout process, and thanks for helping us get to the bottom of this regression. I'm very sorry for the inconvenience.
Are you using the default Python buildpack? Heroku is in the process of updating the Stack image, and especially if you're not using a current buildpack, there may be incompatibilities.
To see if you're using a default buildpack, run
$ heroku config | grep BUILDPACK_URL
Please contact Heroku support if you think this might be the cause.