Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
After each reboot, my Spotlight index seems to break and I only get Dictionary results. I then have to rebuild the index (like add/remove root / to that list in the system preferences for spotlight) and it works fine until reboot. After reboot the same problem appears again.
I think my index first "crashed" after inserting my USB key, but it might only be a coincidence... I think I removed the USB key (iirc via Eject) before Spotlight has indexed it. I am not sure if this is relevant. I have not used my USB key since then, but the problem persists. I am not using any external drives.
Had this issue, registered an account just to post how I fixed it because there's so much crap on the net and most are half-arsed answers.
So yeah, my Spotlight broke after every single time I rebooted. So I had to rebuild the index every single time.
This is what I did, in the order I did it;
sudo diskutil repairPermissions /
I repaired all the disk permissions, seeing as apparently that's what causes it most of the time. Then I rebooted into single user mode (Command-S while booting) and put in
/sbin/fsck -fy
The check came back ok.
Then I entered 'reboot' to reboot the computer and logged back in.
Then I completely nuked Spotlight by;
sudo rm -r /.Spotlight*
sudo rm -r /Library/Spotlight
sudo mdutil -i off /
sudo mdutil -i on /
Then I restarted and logged back in. After this, Spotlight started indexing everything. I also opened up Console (Applications -> Utilities). Select "All messages" under Database Searches on the left. I searched for "mds" and "mdworker" while it was indexing, refreshing it every now and then. I found one file it had errors on, the message was;
Mar 15 16:02:48 CAPTAIN-JEWs-MacBook-Pro /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/Versions/A/Support/mdworker[558]: FontImporter: Validation failed - "/Users/jewishjews/Public/World of Warcraft/Interface/AddOns/MikScrollingBattleText/Fonts/cooline.ttf".
So I deleted that file. Actually I deleted all of WoW because I don't play shitty games anymore. Moving on...
I had activity monitor open the entire time. I was watching the activity of mdworker and mdworker32 (indexing processes). At one point mdworker was sitting on 0% activity, then I checked the indexing progress of Spotlight. It was stuck about 3/4 of the way through, and the time was just increasing, up to about 9 hours. After awhile I got fed up and reset the computer.
After it rebooted I checked again and it was stuck on calculating the time remaining. mdworker wasn't running in activity monitor either. I checked online and some people were going on about md5 failing to hash things, which is why mdworker wasn't running. I couldn't find anything related to it in the Console logs though.
At that point I had to leave, so I just shut the computer down for about an hour. When I got home I booted it up and it started indexing again, and mdworker was running fine. Weird. It finished, and Spotlight was working fine.
Then I decided to reboot, seeing as I lose Spotlight functionality after a reboot. I logged back in and ... it worked fine. I decided to try booting into Bootcamp and then back into OS X to see if that is what messes my indexes up.
So I did that, came back. Then Spotlight wasn't working again, only giving me dictionary results as usual. SHIT. I had the bright idea that I could try removing Bootcamp from Spotlight indexing. I wasn't sure if it would even index it, but I have NTFS Fuse, so it was a possibility.
So I clicked the Spotlight button, searched for something then clicked Spotlight Preferences. Then I went to privacy and added the Bootcamp volume. Then I closed it and tried Spotlight again, and the damn thing worked. So I rebooted. Stopped working. I added Bootcamp to privacy again. It worked again. What the hell?
I rebooted again and tried it again. I searched for Firefox, and nothing came up. So I decided to click Spotlight Preferences again. I saw that the second I clicked Spotlight Preferences it gave me results for the split-second that the Spotlight window is open for before it closes and System Preferences opens. So it seems that adding Bootcamp wasn't what did it.
So I rebooted. Searched, got nothing. Clicked Spotlight Preferences, closed it then searched again. The stupid thing works. I then tried booting back into Bootcamp to see if that would destroy it. I logged back in and Spotlight works without me having to do the Spotlight Preferences trick. I've rebooted/shut down about 15 times so far and so far it is working perfectly.
So yeah, that's how I fixed it. It's still working so for now it's fixed...
Sorry for the rather verbose reply. I just detest people who give really shitty replies or say "dw i fixed it lol" 2 weeks later. Considering the computer-voodoo I had to go through to get it working, I figured I'd say everything I did because to be honest I have NO clue what exactly fixed the evil temptress that is Spotlight.
Related
That is the case as of last night. Does not work for CPU or GPU "compute type"
Basically, after pressing the "Start runtime" button, it says "Preparing project runtime..." for about ten minutes and then stops. It shows the following error, "There was a problem when starting the project runtime. This should be resolved shortly. Please try again later."
I have now tried it about five times over last night and this morning.
There is no way to even access the work that is saved there. The "project" will not boot up.
Basically it is a dud at this point.
Is anyone else experiencing similar issues? What does one do?
The issues/questions and answers that I have learned since (because I was asked to clarify):
(1) The environment on Sagemaker Studio Lab is supposed to be persistent. I.e., any time one starts it, the environment, files uploaded, etc. are where it was left last. However, I was not able to start the environment any longer. Before it locked out, it would start fine. Consequently, I was not able to get to my saved work in any way shape or form. I was wondering if anyone has had this issue
Answer: Thus far not too many people are approved for Sagemaker Studio Lab. So, I may have been the first or one of the first to encounter this issue. As of this writing there does not exist a way to access ones data if one cannot spin up a virtual machine that would have access to the data using their "Start runtime" button.
(2) It is not clear where one is supposed to report issues with Sagemaker Studio Lab. On one's home page in Studio Lab, it has a link to StackOverflow under "Get answers and help others". That is how I ended up here. Though, I should have included the following hashtag (#amazon-sagemaker pointing to https://stackoverflow.com/questions/tagged/amazon-sagemaker).
Answer: I eventually found where people are submitting bug reports. And I reported the issue there (see issue 56). https://github.com/aws/studio-lab-examples/issues
(3) It was not clear to me if I was to delete my account and request a new one if I would be put on a waitlist (which supposedly is presently long). I.e., this would be the manual factory reboot option where one still loses all of ones work, but, at least has an opportunity to start again with the environment.
Answer: Once one is approved, one does not go to the waitlist. Deleting my account, requesting a new one, and setting it up to the initial state took a couple of minutes for me. And yes, I lost all my work that was on there. So, back stuff up as it was your computer in the `80s. I.e., back up externally to that environment.
I signed up for ASMSL about 2 weeks ago. As of this evening (Feb 15) I'm able to log into my runtime without any trouble at all.
Some time ago I've moved from mySql's phpMyAdmin to postgres's pgAdmin 4.
What I've noticed is that pgAdmin's query tool has very slow autocompletion. Usually it's just faster to type keyword/identifier on your own than waiting till autocompletion will appear.
When I click ctrl+space it takes around 0.5-1 second to appear, horrible.
In compairsion when I use autocompletion in phpMyAdmin, it appears almost immadiately.
My question is, does it work so slowly for you too? Is there any way to fast it up? Or I have to use some third party program to get faster autocompletion?
Cheers.
[EDIT]
I've also tried the online trial of pgAdmin and here autocompletion is a little bit faster but still not even close to phpMyAdmin's one.
Just to add to this, the autocompletion has made pgadmin unusable for me. If I briefly pause to think about a query while I'm navigating, suddenly a list will appear over the SQL I'm looking at, and the arrow key context will be hijacked to navigate that list instead, which is, as you can imagine, jarring.
I hope it's the right place to ask such question. I have a live react app which still runs in development mode since it requires frequent updates, and it seems that for a few users the website doesn't function properly while for the others it works perfectly.
For example, for a few users there is a button that just doesn't respond, although I created some code to log to the console that the button was pressed, and it does also for those users, but then the rest of the code just doesn't run.
For other users, there is some text that loaded from mongodb database, and for those users it reverses some of the words in a random fashion.
I'm really lost here and don't even know where to begin, since for me and most of the users everything is working fine.
Do you think it could be because the app still runs in development mode?
Recently I noticed that a few users received the message
the development server has disconnected. refresh the page if necessary.
I researched this and was suggested that I should upgrade my react-scripts. I did, and the problem vanished, but the other problems still persist.
I understand that it's like shooting in the dark and it's hard to give advices without knowing more information, but maybe you could point me in the right direction?
Thank you very much in advance
Very often, when I open File Explorer (on Windows 10) it "hangs", showing empty panels with a search bar on the top slowly moving to the right, with nothing else happening. However, if I open a second (or third, etc....) instance of the same file explorer, it immmediately works showing all the files (while the first keeps on "searching" with no results). If I close everything and re-open the Explorer, once again the first instance hangs on this sort of search activity, while the second works OK.
Unfortunately this behaviour is a bit random (see the "very often" above). I have tried closing any other program that might interfere, but couldn't find anything. I also couldn't find much help by googling it. My guess is that by using the PC at some point I run some program that corrupts something ...
Any hint on where to look?
I just ran into this problem for the umpteenth time, and I definitely found the fix for this iteration. After trying several things, this was the instantaneous fix for the slow scanning bar and slow column sorting:
Navigate to the problem folder in the Window Explorer folder view.
Right-click the folder and select "Properties".
In Properties, select the "Customize" tab.
Make sure "Optimize this folder for:" is set to "General Items" AND "Also apply this template to all subfolders" is checked.
Click OK.
This immediately brought my problem folders to life and everything worked normally. I would recommend doing this at the Drive level folder, and then go back and customize folder such as Pictures, Music, and Videos. The reference that solved the issue is quite old, but still seems to be an issue (and the fix).
Before this I had tried rebooting several times, cleaning out shortcuts, sfc, dsim, and several other things that did not have any effect. Now opening any folder is lightning fast with no scan and sorting by name, type, size, or date modified is just as quick.
Running WSo2 EMM 1.1.0, everything has been working just fine except for one big issue.
From the moment I first click on an app in the App Management tab, the WSO2EMM_DB.h2.db file starts to steadily grow as long as the server is running, even with absolutely no changes. Eventually, it gets so big that clicking an app on that tab takes a ridiculously long time to load the list of devices using the app. We're talking 5+ minutes, it becomes completely unusable. I have checked the error logs and found no errors at all, every time.
Restarting the server does nothing to correct the issue. Even if I click an app on the App Management tab once, and never again, the database file will continue to grow. Even restarting the server and not logging into the EMM page, it will continue to grow.
The only thing I've found so far that can possibly help is keeping backup copies of the database file and overwriting the current file when it gets too big. Obviously that's not a solution, as I'd need to create a new backup file every time there's a change on the server, and eventually the database file would grow too big from that too.
It's not an issue with the H2 database either. Not only have I tried starting over fresh several times and have had the same behavior, but here is the only info I could find regarding this issue, and they were having the issue regardless of whether or not it was on H2 or MySQL.
I've been trying to find a solution for this for over a month with no success. Any help would be appreciated!
EDIT: It looks like this might be the subject of EMM-826. Unfortunately there seems to be no response to that bug report so far.
EDIT 2: EMM-826 was closed with a message saying the following:
This issue is fixed in the EMM 1.1.0 GA latest pack. Please get all the patches for the product/build the product from the latest source [ https://github.com/wso2/product-emm ] and try again.
Unfortunately, that did not work for me. I'm not sure what exactly I'm doing wrong, so I'll list the what I did to try to fix it:
Downloaded the EMM 1.1.0 zip from http://wso2.com/products/enterprise-mobility-manager/.
Downloaded the zip from https://github.com/wso2/product-emm and pasted the files from that into my EMM_HOME directory.
When that didn't work, I searched for patches and found I was only using patches 1-6. In the documentation I found I could download patches 7-12 here. Patches 9 and 10 didn't work right for some reason; causing me not to be able to reach the EMM dashboard or publisher. I could only access the Carbon manager. I was able to make patches 7, 8, 11, and 12 work though - with no change in behavior.
Here are the steps I take to reproduce the issue:
After setting a fresh copy of the EMM up, I log in to the EMM dashboard as Admin, set up a user account, and upload an app through the Publisher.
Register a device to the user account I set up. In this case, an Android device running Android 4.2.2.
From the dashboard, I go to App Management and click the app I uploaded. The list of devices loads, but from that point on, the database file starts growing and eventually, after several hours, becomes so large it the device list will never load.
Please help!
Found this happening also, from a quick look it's the WSO2EMM_DB.notifications table. Seems to keep a history of all notifications over time, and the info for app installs is taken from non-optimized queries, which degrade as the table grows. You 'could' delete all rows from the table, and it will re-populate as devices 'check back' and report their info.
But you'd probably want to write a query to just keep the latest notification of each type of each user (I'll leave that to someone else...) and as was mentioned, it is apparently fixed in the latest version.
Issue appears to be resolved in EMM 2.0, which can be found here.