Everything works fine for most accounts 100% of the time but here and there some users who are able to access a subsite fine one day are greeted with a standard 404 the next. This can last for an hour or two days, it's really inconsistent.
I check the iis logs and it says the status is also a 404 for these requests, nothing else looks unusual. Sharepoint logs have nothing for the timestamps either.
Correct me if I am wrong but if it was a permission issue an access denied message would be shown.
It is not the individual computer because when a user is having this problem and I can log in with their account and I also get the 404 error although I am on the exact site with another account in another browser at exactly the same time, and it works perfect.
Any suggestions would be greatly appreciated, I've done a fair amount of searching but can not find a similar situation or help anywhere.
Since the information is very strict at the moment, I will throw a few questions that might lead you towards the problem.
Are we on a loading balance setup? The intermittent 404 might be cause by one of the servers Web FrontEnds not correctly serving requests.
Are we running out of disk space in the SQL Server machine? This might cause it
Are the blogcache or site caches enabled? Some routines may break them
Do we have Anti-Virus on the server? (it HAS to be asked :p)
We get very high packet loss between the servers? (The error would be different though)
Something that might occur very often is when you have, say, custom code a DLL on the GAC or the bin folder, and since you could be on loading balance the second server does not have this DLL in its own GAC or BIN folder. Sharepoint usually raises 404s when assemblies are not found too, not only requests.
This seems like a longshot, but... could those SharePoint sites be throwing a 404 HttpException? It seems like you'd see that in the SharePoint logs, too, so it's even more unlikely.
At any rate, is your SharePoint logging level set to an appropriately verbose level to debug weird stuff like this?
Are people checking in & publishing master page changes when new CSS files and/or other includes (script files, etc.) are not yet published at all? I've seen this cause a 404 a few times when users forget to check before they publish.
I have had to write custom code within a SharePoint context and I had those 404 errors as well. The solution, in my case, was to ensure that the block of code executing had these 2 conditions met:
1) Run with elevated privileges, regardless of the fact that it is a 404 this was part of the solution.
2) web.AllowUnsafeUpdates = true; This line of code needed to be added even though it was wrapped within an elevated privileges block.
Once these were added the issue did not occur. This was happening on both load and non-load balanced environments.
This reminds me of a strange asp.net bug that I had a few months back.
It was caused by a patch that had been applied (to the framework if I remember correctly)
try downloading this Windows update list tool and have a look at what has changed since the problem started.
I concede that if there was a problem with a patch then its more likely that it would be a consistent error, but it's worth a look.
It was a permission issue, I had figured this out awhile back but basically a few accounts were not setup properly and could not load a fresh copy of the page, when someone else would hit it they would be able to view the cached page fine. Error was never thrown as a permission issue or access denied anywhere but this is what fixed the problem.
Related
I have just installed Wordpress in a new Azure Web Application and everything is running fine at the moment.
However, I am getting notifications that I am exceeding the storage file system quota (1GB).
I went to check the value on the Azure Portal and the strange thing is that the storage usage is varying from 12% to 100% every single minute! Somehow the measurement must be crazy, since I am not changing a bit in my website nor have huge files there.
12% must be the realistic value for Wordpress. I have tried to reset the website and check log files to see if there is anything wrong, but did not find anything.
How can I fix that?
Igor.
You might want to try de-activating the most recent plugins you installed 1 by 1 to see if this corrects the issue. There could be a bug in one of them that has some type of loop that generates a large log file.
At the end of the same day the problem disappeared. It seems everything is stable now, but if happened once, it might happen again. I will keep you posted in case I experience this problem again.
Thank you.
I have an ASP.NET MVC5 website and I have installed Glimpse.MVC5 using nuget. The website is running the latest version of the Sitecore CMS (7.2 rev. 140314). I haven't changed the Glimpse configuration at all apart from adding logging.
When I go to the homepage of the website (after enabling Glimpse) I can't see the HUD. The following is the last line in the Glimpse log:
2014-04-24 15:19:01.6043 | DEBUG | Apparently GlimpseRuntime has not
yet initialized this request. This might happen in case you're doing
something specific like mentioned in this issue:
https://github.com/Glimpse/Glimpse/issues/703 . Either way, Glimpse
will be disabled to prevent any further non-deterministic behavior
during this request.
I've had a look at the link but I can't see that it applies to my situation. There are no NullReferenceException's in the log.
I have tested Glimpse.MVC5 with a vanilla ASP.NET MVC5 website on my machine and that worked fine so I'm tempted to assume that it's something to do with Sitecore.
Any ideas what could be wrong or ideas on how to identify the issue?
The solution mentioned in this post on the Glimpse issue tracker solved the problem.
Sitecore does it's own HttpModule stuff which seems to
cause issues.
In order to fix this, you need to move the Glimpse HttpModule
definition before the Sitecore modules in the Web.config.
The reason why you are still not seeing the HUD is explained by that log message as well.
Somehow during the execution of the request, a new HttpContext is created or used which means you'll loose the request initialization that Glimpse did at BeginRequest. As part of that initialization, items are being stored in the HttpContext.Items collection for which Glimpse will look during request monitoring.
The message you see in the log is an example of when Glimpse wants to know what the current RuntimePolicy is, so that it knows whether or not it should continue to monitor that request. The current RuntimePolicy is set by Glimpse during the BeginRequest phase of that request and the log now indicates it cannot find it, after which Glimpse decides to be concervative and stop monitoring that request instead of ending in a NullReferenceException
Now the cases where we've seen that (check the linked issues inside the issue you mentioned) is when another HttpContext is being created and used to process that request after that Glimpse did is initialization.
So the only advice I can give here, is to check whether the creation of another HttpContext is actually the case for you? You might find some ideas in those linked issues.
In case you find something specific that is not related to the issue mentioned above, then I would suggest you create a new issue on our issue tracker as it is a more appropriate place to discuss potential bugs or missing features
I'm using liferay portal community edition 6.1-
I'm trying to export a portal in order to move the content to another intance of liferay. however, when trying to export the portal content the export fails with message 'Your request failed to complete."
When looking at log files, there is no sign of anything going wrong.
Could someone please explain to me what can possibly be wrong, and from where should I get the information for what is failing on server?
Marko
I've been digging into similar issues with the LAR importing/exporting system myself. There isn't much logging in that code unfortunately. I ended up enabling remote debugging in the server's JVM and stepping through the problematic tasks using the Eclipse debugger.
One of the main issues I've had with Liferay is that it swallows detailed exceptions, doesn't log them, and waters them down into very generic error messages by the time they're displayed to you in the UI. Using the debugger really helps because you can often see the original exception without having to dig too deeply into the code.
How's your free disk space looking on the server? I believe Liferay saves the LAR to a temp file as it works on it (at least, it does as part of the publishing process). On our test site, with only ten pages and almost no content, that temp file is still 3.5M. If your site is really big you might just be running out of space.
I've found plenty of versions of this questions, but neither seem to go further than an apparent Google Chrome bug.
What happens is that whenever I copy a codeigniter setup to a new folder on my server, to start a new project based on it, I get "no data received" in any browser I try it on.
The strange part is that the problem is solved if I go into each file that gets include()-d, add or change something irrelevant (like a blank space) and save the file. I don't know why, but this makes that specific include() work. Otherwise, the script stops before it.
There's nothing logged in the server's access or error logs so I can't figure out what the problem might be.
Needless to say this has been driving me crazy. Any suggestions?
Thanks!
My sysadmin figured it out. It was related to system wide APC cache. I used apc_clear_cache() at the top of index.php and everything works like a charm!
I've been struggling with a problem now for a few hour and I cannot find any answers or anyone with the same problem -
Some menu items are missing on my site www.namhost.com (Drupal 6.22) and when viewing the blog it shows "No blog entries have been created". When I log in as admin everything works fine, so this problem only occurs for anonymous/guest users.
I've changed nothing on the site which may have caused this problem and here comes the really strange part - When viewing a copy of the site locally everything works 100% even for anonymous/guest users.
I've tried:
flushing caches
rebuilding permissions
checked if the "anonymous" user is present in the database
viewing on different browsers
None of these yielded any results.
Because the problem doesn't occur locally I'm starting to believe this could be a problem on the server the site is hosted on (Linux with PHP5.2), but the admins had a look and couldn't find anything.
Any help/insight would be highly appreciated.
================FIXED<<<<<<<-----------------------------
I am not allowed to answer my own question and it was suggested that I edit the question to include my answer so here goes:
Firstly, thanks for all the responses.
I disabled the "ACL" module (http://drupal.org/project/acl) and the problem was solved. It was previously used for our forum which was also disabled a few months back, so it's not needed any more.
I still have no idea why this module caused the site to work locally but not on the server. I will be in contact with the server admins to find out if they changed/updated anything on the server which may have caused this module to cause a malfunction.
Any insight could still be helpful top prevent this from happening again.
Check your Drupal config:
Are you using node_access, content_access, or any other permissions-related addon mods? Disable them and see if the problem persists. If that doesn't work, disable all non-core mods and re-enable them one-at-a-time until you find the offender.
Compare your hosting configs:
If it's not related to Drupal, compare the local and remote server configurations. Do both use the same versions of php, apache, apc, cgi, etc.? A phpinfo(); on both servers should give you the most important details for comparison. Do a similar comparison of the MySQL setup and content. Finally, check for differences in your .htaccess files (if any) between the two locations.
Test another hosting enviornment:
Download a virtual appliance like QuickStart which is already configured to host Drupal sites for development and non-production purposes, and see if the site works correctly in that. If it does, you could do an additional validation by porting to a new host who offers a trial/money-back-guarantee and see if it works correctly there.
If your site works fine elsewhere, give your current host a good thrashing for making you go through all of this to figure out the problem lies on their end.