I'm working on a Tiki Wiki and ran into this error today
I have tried disabling the search feature all together and still the error wont stop, any help would be greatly appreciated
Check your server directory permissions. Tiki requires write access to your ../temp/unified-index/ directory.
What we had to do was actually set up a Cron Job that rebuilt the search index ever 10 minutes
Related
I am using Tiki Wiki, and I change to login with an LDAP server, I already made all the configurations but when I try to login with a user from my LDAP server give me a blank page. I saw a solution on TIKIWIKI doc's, they say to clear the cache but I dont know how to clear.
You can clear the Tiki caches by going to tiki-admin_system.php when logged in as an admin, there is a link on the Settings part of the main Tiki menu, and one on the Quick Admin module (if enabled).
You can also clear the cache from the command line by doing
php console.php cache:clear
More info here
(however, if you are running Tiki 16.2 there is a bug in LDAP which also produces this sort of blank page error. This will be fixed in 16.3 which will be released soon, in the mean time you can download a nightly build from here)
i have a running Typo3 7.6.11 installation on my webhoster.
I noticed that the extensions "powermail" and "dynamic content elements" get somehow automatically deactivated over night.
I can activate them in the Backend via Extensions, but the next morning they are both deactivated again.
Any ideas on that?
What cron-jobs and scheduler-tasks are configured? at what time?
the next I would do is writing a cronjob, which logs every 5 minutes the md5-hash of your PackageStates.php into a file. if the file is modified the hash should change and you nearly know the time the change occurs. compare to cron-jobs/ scheduler-tasks running at that time.
Check the system log of your installation, if someone else did not login during night into your system. If no-one did, contact your webhoster, since someone has is changing your files directly on the system, so they should be able to figure out if it is some security issue or maybe some faulty backup procedures.
In the Install-Tool there is an option to do a check for broken extensions and after the check the "broken extensions" are deinstalled automatically. May be you have a task running in the scheduler that does this routine?
Normally after a system update some of the extensions are broken because they use a deprecated api and also have to be updated, so you should also check if there is an update for these extensions.
do you have an automatic deployment?
does this deployment know that these extensions needs to be active?
Please check permission of typo3conf/PackageStates.php file, Is there any cron-job that automatic deactivate extensions.
If not then try to overwrite extensions with new vesrion.
I have been following the instructions on
https://docs.adobe.com/docs/en/aem/6-1/deploy/upgrade.html
I reached "Once the upgrade is finished, the AEM homepage will be shown."
However, all I get is "an HTTP 503 status for all requests except for those under http:///system/console", exactly as described at the NOTE under this step.
The problem is that I always get this error, not only during the upgrade, but also after the upgrade is finished!
The error.log states:
11.11.2015 12:38:29.888 *ERROR* [qtp231586654-77] org.apache.sling.engine.impl.SlingHttpContext handleSecurity: AuthenticationSupport service missing. Cannot authenticate request.
11.11.2015 12:38:29.888 *ERROR* [qtp231586654-77] org.apache.sling.engine.impl.SlingHttpContext handleSecurity: Possible reason is missing Repository service. Check AuthenticationSupport dependencies.
Any help is highly appreciated.
We've encountered this once:
There were issues with diskspace (the disk was simply full), make sure you have an adequate amount of space available.
There could be two possible reasons:
Some of the bundles are not active.
Lucene is corrupt and hence not able to start
Possible fix is:
Bring your bundles back to active, if it is not active.
Stop your instance. go to crx-quickstart\repository\index and delete index folder.
Restart the instance (This will regenerate Lucene indexes fully).
Quick fix:
Stop the AEM instance.
Go to folder crx-quickstart\repository\ remove folder index
Start the AEM.
Everything should working fine. (It's working for me)
Check the permissions under crx-quickstart\repository\ after you deleted the index.
For me it had nothing to do with the segmentstore or the index or any unsatisfied bundles. Instead, it was the datastore.
The permissions for the datastore directory didn’t allow the user running aem to access it. The datastore directory is configured in org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.
This error really should reveal its root cause a little bit more easily. I’m sure it was somewhere in the logs, though…
At present I cannot run it (SQL Developer 4.1) because it hangs on "Restoring Editors" while starting. I suppose I've done it by exiting it before by killing sql developer process because it was hanged on fetching objects to Schema Browser so long...
Maybe I would clean some temporary files but can't find any.
Any ideas?
Deleting files from c:\Users\MY_USER\AppData\Roaming\SQL Developer\SQL History
and c:\Users\MY_USER\AppData\Roaming\SQL Developer\System...
Really helped me to resolve the connection issues
Basing on this thread https://community.oracle.com/thread/2564842 I've created own solution.
Extract installation of current version SQL Developer (4.1.0.17.29)
At "c:\Users\MY_USER\AppData\Roaming\SQL Developer\"
I've changed directory name system4.1.0.17.29 to system4.1.0.17.28.
After running newly extracted SQL Developer (4.1.0.17.29) I was prompted to let copy configuration from version 4.1.0.17.28 to 4.1.0.17.29 ;)
Everything works great now. I suppose that running the same (broken) installation after decreasing version could also help.
Remove folders c:\Users\USERNAME\AppData\Roaming\SQL Developer\system4.1.3.20.78\system_cache*. SQLDeveloper will recreate it after launching.
Just execute sqldeveloper as administrator. It works fine!
In my case the problem was because of windows compatibility issue. So I've selected my windows version and it's stop from randomly crash after startup
Our setup:
Windows 10
Sqldeveloper Versions <= 20.4.0
We observed this problem as well. Even worse while working over a VPN connection. I followed a couple of hints with more or less no effect.
To move
C:\Users\<USER>\AppData\Roaming\SQL Developer
to a local directory by adding this line
AddVMOption -Dide.user.dir=c:\temp\sqldev-conf
in the \sqldeveloper\bin\sqldeveloper.conf file gave us some improvement, but the “IndexPreferencesTask” still got stuck several times on startup.
After some more hours on unsuccessful research, we moved back from JDK 11 to JDK 8.
This solved 99% of the problem. The “IndexPreferencesTask” still hangs on startup but for less than a second.
Sounds to me like a problem with JDK 11.
In my case when i changed Tools --> Preferences --> Environment -> Look and Feel to Windows it is solved.
Delete the History files from C:\Users\User\AppData\Roaming\sqldeveloper
Restart the PC
In my case, the solution was kind of weird. After battling to resolve this for 2 days, no luck. Suddenly, on my mac, I searched for sql developer, not sqldeveloper. It popped up a sqldeveloper application (not sure how that is different from what I have been trying to open ), clicked it and boom, it opened. My guess is that there is a copy of that app on my system that I should have been opening rather than trying to open the reinstalled app. Note: I reinstalled the app after it started misbehaving though.
Operating System: Windows 10
Oracle Sqldeveloper Ver: 17.4.0
The problem has been noticed sometime when any network security
patch was installed on your machine. Looks like the patch impacts
your cached data under your user profile folder.
As above Lakh, rtbf and others answered. Removing below folders
will resolve the issue.
C:\Users\<userId>\AppData\Roaming\SQL Developer\SqlHistory
C:\Users\<userId>\AppData\Roaming\SQL Developer\system17.4.0.355.2349
If any one find more approriate reason please feel free to
disagree with my answer.
I am in the middle of rebuilding my VPS and I am getting an error in WHM.
CENTOS 6.5 x86_64 virtuozzo – vps-1......... WHM 11.34.2 (build 8)
Reasons for blocked updates
Please correct these issues and rerun updates.
fatal: Upgrade is blocked because EXIMUP is set to 'never' in your configuration. To proceed, you can touch file '/var/cpanel/exim.unmanaged' and run the upgrade one more time. Please refer to our documentation at http://go.cpanel.net/1136UpgradeExim for more information.
The URL for help doesn't exist.
I do not see this file in when I check for it.
I found the Exim Configuration Manager but do not see anything that matches what the error states.
I have a feeling this is fairly easy fix but I am far from an expert on VPS managing. I'm learning the hard way to put it nicely...
Does anyone know how I can clear this out so I can upgrade WHM?
I see in their documentation:
To upgrade from cPanel & WHM version 11.34 and earlier:
Touch /var/cpanel/exim.unmanaged
Run the upgrade again.
What does "Touch"mean? I tried toggling the exim option in preferences but it made no difference.
After a night of fighting this I find the answer right after I post. Here is how I solved it.
Touch means to create or modify a file without actually writing to it. So in this case since the file did not exist. I created a new file in /var/cpanel/ called 'exim.unmanaged'
After placing that file in the directory I ran the updates again and it is now upgrading WHM and cPanel.
Pros know this I am sure but hopefully this will be helpful for newbi VPS admins like myself.