I am following the tutorials on the Windows Azure Node.js site:
http://www.windowsazure.com/en-us/develop/nodejs/tutorials/
however my server.js.logs file isn't being created?
In my server.js file I am issuing console.log statements but none are written to the log file. Why is that? Whats changed in the August SDK to prevent my logs from being written?
Or what do i need to enable in order for console.log statements to be written ?
Thanks
See https://github.com/tjanczuk/iisnode/issues/168, linked to from https://github.com/tjanczuk/iisnode/wiki/iisnode-releases (the v0.1.20 notes).
The latest Windows Azure Node.js SDK must have picked up a newer version of iisnode, and iisnode changed where it puts the log files.
Yes, iisnode now puts log files in the ~/iisnode directory, and writes an index to the log files you can browse. It also contains a new node.js script, interceptor.js which allows you to write log files to any location
You must understand that console.log in node.js is used mainly for client side logging. I just tested that when you are using console.log in node.js application running on Windows Azure stdout log file could not be created so you will not get any log.
If you want to add logging to your code which is running on a web server you should be using server side logging code and I found connect library is most powerful and useful for such purpose:
https://github.com/senchalabs/Connect
As you suggested your code is running in Compute Emulator means you are creating Windows Azure Cloud Service, you should follow your the below article step by step and you will get it working:
https://www.windowsazure.com/en-us/develop/nodejs/tutorials/getting-started/
Be informed that still console.log will not show anything when your node.js code is running in Compute Emulator.
Related
I'm running an Azure function in Azure, the function gets triggered by a file being uploaded to blob storage container. The function detects the new blob (file) but then outputs the following message - Did not find any initialized language workers.
Setup:
Azure function using Python 3.6.8
Running on linux machine
Built and deployed using azure devops (for ci/cd capability)
Blob Trigger Function
I have run the code locally using the same blob storage container, the same configuration values and the local instance of the azure function works as expected.
The functions core purpose is to read in the .xml file uploaded into blob storage container and parse and transform the data in the xml to be stored as Json in cosmos db.
I expect the process to complete like on my local instance with my documents in cosmos db, but it looks like the function doesn't actually get to process anything due to the following error:
Did not find any initialized language workers
Troy Witthoeft's answer was almost certainly the right one at the time the question was asked, but this error message is very general. I've had this error recently on runtime 3.0.14287.0. I saw the error on many attempted invocations over about 1 hour, but before and after that everything worked fine with no intervention.
I worked with an Azure support engineer who gave some pointers that could be generally useful:
Python versions: if you have function runtime version ~3 set under the Configuration blade, then the platform may choose any of python versions 3.6, 3.7, or 3.8 to run your code. So you should test your code against all three of these versions. Or, as per that link's suggestion, create the function app using the --runtime-version switch to specify a specific python version.
Consumption plans: this error may be related to a consumption-priced app having idled off and taking a little longer to warm back up again. This depends, of course, on the usage pattern of the app. (I infer (but the Engineer didn't say this) that perhaps if the Azure datacenter my app is in happens to be quite busy when my app wants to restart, it might just have to wait for some resources to become available.). You could address this either by paying for an always-on function app, or by rigging some kind of heartbeat process to stop the app idling for too long. (Easiest with a HTTP trigger: probably just ping it?)
The Engineer was able to see a lower-level error message generated by the Azure platform, that wasn't available to me in Application Insights: ARM authentication token validation failed. This was raised in Microsoft.Azure.WebJobs.Script.WebHost.Security.Authentication.ArmAuthenticationHandler.HandleAuthenticate() at /src/azure-functions-host/src/WebJobs.Script.WebHost/Security/Authentication/Arm/ArmAuthenticationHandler.cs. There was a long stack trace with innermost exception being: System.Security.Cryptography.CryptographicException : Padding is invalid and cannot be removed.. Neither of us were able to make complete sense of this and I'm not clear whether the responsibility for this error lies within the HandleAuthenticate() call, or outside (invalid input token from... where?).
The last of these points may be some obscure bug within the Azure Functions Host codebase, or some other platform problem, or totally misleading and unrelated.
Same error but different technology, environment, and root cause.
Technology Net 5, target system windows. In my case, I was using dependency injection to add a few services, I was getting one parameter from the environment variables inside the .ConfigureServices() section, but when I deployed I forget to add the variable to the application settings in azure, because of that I was getting this weird error.
This is due to SDK version, I would suggest to deploy fresh function App in Azure and deploy your code there. 2 things to check :
Make sure your local function app SDK version matches with Azure function app.
Check python version both side.
This error is most likely github issue #4384. This bug was identified, and a fix was released mid-june 2020. Apps running on version 3.0.14063 or greater should be fine. List of versions is here.
You can use azure application insights to check your version. KUSTO Query the logs. The exception table, azure SDK column has your version.
If you are on the dedicated App Service plan, you may be able to "pull" the latest version from Microsoft by deleting and redeploying your app. If you are on consumption plan, then you may need to wait for this bugfix to rollout to all servers.
Took me a while to find the cause as well, but it was related to me installing a version of protobuf explicitly which conflicted with what was used by Azure Functions. Fair, there was a warning about that in the docs. How I found it: went to <your app name>.scm.azurewebsites.net/api/logstream and looked for any errors I could find.
I'm trying to run an .exe during a release pipeline on Azure DevOps.
In order to do so, I'm using a Command Line Script task where i just "invoke" the .exe file.
It works as it's correctly launched but i cannot see the output of the .exe (that is a .net framework 4.7.2 Console Application).
I've used a simple "Console.WriteLine()" method in the Console App in order to dump the messages. Obviously, on local machine it correctly writes messages on the console output. On Azure DevOps...just the Std Errors.
Why? How could I dump application messages to the task log?
Thanks
My bad. After different tries and retries i've found that the problem was related to a wrong dependency (resolved via reflection at runtime) that was causing exceptions before any log was written.
So, in fact, it works as expected.
I have an elasticbenastalk (eb) web node.js application in a working environment.
I'm using a well built zip file in order to deploy.
The thing is that after deploying, eb dashboard displays a green status and the correct version number for the application (the one I want to deploy). This should be the expected result (api-0.0.22 is the latest available version).
However, in a randomly manner, the deploy software doesn't change (I have a version file in order to confirm which is the effective deployed version). When I detect this, I also can see a timeout in the events' log that confirms the non-deployment.
I've gone through the available logs and I couldn't find any attempts to download the software from S3 nor installing it. I mean that is there not only a lack of errors but also a lack of proof of the deployment. It looks as if 'it never happened'.
I'm also using one ebextension for logging (logging.config):
files:
"/opt/elasticbeanstalk/tasks/bundlelogs.d/01-appname.conf":
content: |
/var/app/current/log/error.log
"/opt/elasticbeanstalk/tasks/taillogs.d/01-appname.conf":
content: |
/var/app/current/log/error.log
Note: /var/app/current/log exists in the application file tree
I've been making lots of tests and one of them gave me a little light over the dark: if I terminate the eb related instance that timeouts, eb launches another one with the correct (and expected) application version.
I don't know if this issue could be code related (that is why I'm using stack overflow) or eb setup or deployment method.
Any suggestions/ideas will be very appreciated.
I am using Azure node js emulator.
from power shell, I was able to start the :
start-AzureEmulator.
in my server.js, I have :
console.log();
I dont see these logs written on power shell .
where are these console logs written?
By default logs are written to a logs folder within your project folder. You can also view the logs realtime by right clicking on the emulator taskbar icon and then viewing the emulator ui.
I think you need to use Node Inspector (Chrome/Safari/FireFox)
More here "Using node-inspector to debug node.js applications including on Windows (and using ryppi for modules)"
There might be other simpler ways but this should work.
I am facing a problem while starting the websphere message engine for one of the application deployed on websphere. This application is getting deployed automatically as a part of the installation of Websphere Lombardi 7.2 express edition. It's using websphere 7 internally to deploy it. When I try to start the message engine from the administrative console of websphere I am getting following error:
The messaging engine ProcessCenter01.twperfsvr-twperfsvr_bus cannot be started as there is no runtime initialized for it yet, retry the operation once it has initialized. For the runtime to successfully initialize the hosting server must be started, have its 'SIB service' already enabled, and dynamic configuration reload enabled. If this is a newly configured messaging engine and it is the first messaging engine to be hosted on this server, then it is most likely the 'SIB service' was not previously enabled and thus the server will need to be restarted. The messaging engine runtime might not be initializing because of an error while trying to start, examine the SystemOut.log of the hosting server to check for error messages indicating the problem.
After restarting the server, the same error shows. Can anyone help me to to find what gets loaded as a part of "initialization of runtime"? Are there any config files etc. that I need to check to solve this issue? I am suspecting some missing configuration causing error to load the runtime for this particular application.
I too faced this issue today had to delete all the files under the message store
check the directory-file path mentioned in
Application servers > server1 > Messaging engines > XXX.server1-primaryBus > File store
Just Enable the SIB Services For the particular Server.
Example:Server-->Application Server-->click on Server Name-->right hand side we can see SIB services-->Check box the Enable services.
This will solve your problem
Recently I have faced the same issue when I rebuilt the jvms in UAT envt. After searching on web I found that because of the old messages saved in the message store(flat files in my envt) the messaging engines was not getting initiated. After deleting the old messaging store and restarting the servers it got initialized.
I have struggled with this problem too.
In our situation the problem was that the file message store location was used that was already created for a different (or old) message-engine.
If you add a busmember to the service-bus and use a file store implementation, then you need to supply the path for the store and log folder. Make sure these locations don't exist yet, other wise you will run in the problem above. The message-engine for this member will use these folders.
If you have a script for creating the message-bus infrastructure, make sure that when you delete the bus or remove message-engines, that you remove the file store/log folders for these, before you re-run your script.
Another possibility is that you are using a external database as a data store, and the user that is used for the connection is not allowed to create a database. You might find a ffdc entry like this:
DB2 SQL Error: SQLCODE=-552, SQLSTATE=42502, SQLERRMC=DB2ADMIN;CREATE
SCHEMA, DRIVER=3.61.65
Then you have to go to your database administration tool and give DB2ADMIN the proper privileges. Then restart the server or cluster.
Finally this issue is been resolved. I did not create the schema in SQL Server with same name as that of the username I gave to connect SQL Server during the installation of WLE 7.2
Please find details about this at below link:
http://www.ibm.com/developerworks/forums/message.jspa?messageID=14795282