We have CouchDB 1.5.0 installed and running successfully on a Windows 2008 server. Everything has been working fine for several months, but lately it's started crashing with little information in the logs.
I found local.ini and changed the [log] setting from error to debug, then restarted the service. Everything seemed to work fine, except the setting in local.ini automatically reverted back to error. I downloaded and ran Process Monitor and determined that erl.exe is the guilty party for updating the .ini file.
I even tried removing the [log] block entirely from local.ini to try to grab the default value. When I do this, the erl.exe process comes back through and adds back the [log] block, with the log level set to error.
Am I missing something? Obviously the purpose of local.ini is to override default values. I've seen nothing that indicates why some settings, like the log level, cannot be changed. Process Monitor tells me that the only .ini files being accessed are default.ini and local.ini, so I think I can rule out an extraneous .ini file somewhere that's mucking up the settings.
I'm really at a loss for how to debug our crash if I can't even get more logging info out of the server.
Can you try using Configuration page in Futon? It should do the right thing™.
Related
OS: Ubuntu 22.04 | CommandBox Version: 5.5.2 | Lucee Engine: 5.3.9+141
Having a really strange issue. I've installed CommandBox from scratch and am using the Lucee engine. Everything works fine until it's time to pull my web files from GitHub. Initially, all the files are served properly, but upon restarting the service, it is unable to start. I've tried a couple of things (changing user/group ownership, copying the files manually, even changing file permissions for the folder and everything inside) but it fails to start every single time.
I'm able to bring it up by deleting the web root folder and recreating it. I'm also able to run files that I create locally with echo/touch no problem. Kind of at a loss here as to where to go from here.
It sounds like the number of files in your web root are causing the XNIO directory watcher to take some time starting up. you can disable it like so:
server set runwar.args=['--resource-manager-file-system-watcher=false']
And the restart the server. Please note, this setting will actually be disabled by default in the next version of CommandBox due to occasional issues like this.
I have a Azure App Service app that I'm trying to get deployed.
Today I ran into an issue where .NET informed me (via the yellow screen of death when I browse to the URL of my app) that I had a missing DLL (for the purposes of this question I don't think it really matters).
I used FileZilla to publish my changes in an attempt to do a manual deployment first and then work my way to automate it.
After so many attempts to fix it I later realized that the error message never changed. I did something more severe and renamed my bin folder into something completely different and the exact same error message would appear.
I've stopped the service, restarted it, and as mentioned, renamed folders, etc. and still the exact same error message persisted.
I also decided to open up the Azure Portal Console for my App Service app to browse a bit and to my amazement, nothing seemed to have reflected at all. The FTP shows one thing and the Console shows another.
Would anyone have any idea as to why this is happening?
I eventually got it to work and I will share what I tried.
I deleted the web app and created it again (I found this to be important the first time around). This was quite time consuming and did help but it wasn't long before the same problem happened again.
Then I finally found a solution that seems to give me consistent results:
I kept on editing the Web.config which seems to force a recompile and clear some sort of cache. So each time the web app stopped updating, I would make a slight change in the Web.config, upload it via FTP and the app finally updates.
If anyone has any more details on this, it would be greatly appreciated.
My Azure Functions were running fine and all of a sudden I am getting several "Assembly changes detected. Restarting host..." messages that is preventing my functions from completing.
I am not deploying new code so not sure what is triggering the Assembly Change event to fire. I was running on the latest version of the runtime and have since reverted to version 1.0.10947 thinking that maybe the underlying runtime was updated, but I'm still getting that line showing up in the logs.
Update
Now that #Alexey has helped me track down what is causing the Assembly changes to be detected. I would like to ask if anyone can tell me WHY an assembly change is being detected even-tough I have not changed/redeployed my application.
After looking in your logs we opened an issue https://github.com/Azure/azure-webjobs-sdk-script/issues/1533#issuecomment-303595960.
Your functions had multiple restores but now issue is gone. Restores could be initiated by changing project.json.
If you are stuck with the multiple
Assembly changes detected. Restarting host
I fixed my issue by deleted the log file in the Kudu services:
https://[FunctionAppName].scm.azurewebsites.net/
and follow on the top menu:
Debug Console >> powerShell
And the file log is :
LogFiles >> Application >> Functions >> function >> [Function name]
You can remove the log file.
my 2c.
I was struggling with this issue for ages and not sure what was causing it. I believe I may have the answer.
Our solution has been toying with consumption plans, but pulled back to full App Service Plans because the initiation times were too long for our rather unique usage patterns.
But 2 of the appsetting params were still in place: WEBSITE_CONTENTSHARE And WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.
per:
https://learn.microsoft.com/en-us/azure/azure-functions/functions-app-settings#websitecontentazurefileconnectionstring
these are ONLY for consumption plans.
I removed them and... touch wood, the issue seems to be resolved.
As the title says.
I tried adding com.liferay.portal.servlet.filters.monitoring.MonitoringFilter=false to my portal.properties but it still seems to be enabled. (getting a response already commited exception on it).
And since it only occurs at the customer and we're not monitoring the performance it seems best to turn it off.
Any input is appreciated.
(liferay-6.0.5)
Be extra extra sure that the portal-ext.properties you mention (you didn't refer to portal.properties, right) is really picked up - there will be a log entry at startup stating which portal-ext.properties is being read.
Put your portal-ext.properties in LIFERAY_HOME, that's the same folder that also has the tomcat, data and deploy folders (if you're on the tomcat bundle).
Also, on Windows, make sure that Windows shows also the extensions. I can't count how many times people created portal-ext.properties.txt and wondered why it wasn't picked up. (this file is only renameable on the command line, not in Explorer, if you have the "hide extension of known files" on.
I am experiencing the same issue as you and can confirm that the IllegalStateException will still occur even the monitoringFilter is disabled. The exception seems to occur on the filterChain, not actually on the MonitoringFilter. See http://issues.liferay.com/browse/LPS-13853
I'm just taking my first steps with Azure and the first thing I see in the development fabric is a bunch of console style logging windows. So I figure that's going to be handy and decide to figure out how to write stuff there and stumble upon this:
Microsoft.ServiceHosting.ServiceRuntime.RoleManager.WriteToLog("Information", "Message);
Cool, except I don't see anything in the log. Saw a post somewhere that after first install you need to reboot before this will work, so I tried that but still nothing.
I've checked with a break point that the code is executing and I've checked the logging level in the dev fabric.
Is this supposed to work, or am I completely off base?
Just to add some more information about what I'm doing:
Started with VS08's new project wizard for Cloud Service
In the wizard added a single ASP.NET Web Role project
In the Page_Load method in Default.aspx.cs I added the WriteToLog line shown above
Ran the project and in the dev fabric UI, drilled down the tree to web role instance "0"
Nothing in the displayed log except some role instance start up messages followed by a bunch of health status messages.
Tried reloading the page a few times, the breakpoint in Page_Load gets hit but nothing in the log.
Logging Level is set to information, and the other events are level information so I don't think it's a logging level issue.
Logging level is the common gotcha, but there's also a delay before logs start showing up in the dev fabric, so make sure that this message is getting logged at least 10 seconds after the application starts.
After some more googling, seems like this is a known issue:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=481184