I noticed every time I launch a Playground in Xcode (version 9.3) a daemon starts in the background and uses more that 100% of my CPU!
I deleted Xcode's cache and its DerivedData folder but no change.
Does anyone know how to resolve this problem?
diagnosticd is a daemon you need to stop/kill with launchctl. The daemon you most likely need to stop has 'SimDevice' in its name. To get the exact name do:
/bin/launchctl list | grep SimDevice
Then with the appropriate name(s) (there could be more than 1) do:
/bin/launchctl stop 'name'
In my case 'name' was: com.apple.CoreSimulator.SimDevice.380EFF06-B636-49CD-851E-5DB4890641AE
If you use Playground a lot and you usually have more than 1 simulator eating your CPU run this script instead:
/bin/launchctl list | grep SimDevice | awk '{print $3}' | xargs -I %s /bin/launchctl stop %s
Oh, and dont forget to file a bug report with apple here: https://bugreport.apple.com/web/
Btw, its kinda fun to see playground/diagnosticd struggle with your code; if you create a bug or some other elaborate syntax, cpu goes up. If you clear it, cpu goes down (just a bit). Almost hilarious how Apple implemented this...
As a temporary workaround, I run this script after starting up a playground to kill the rogue diagnosticd and homed processes:
#!/bin/bash
kill $(ps -ef | grep Xcode.app | egrep "diagnosticd|homed" | awk '{ print $2 }')
Edit: This seems to be a problem with iOS playgrounds only, so another (less drastic) workaround is to use a macOS playgrounds for those cases where no UIKit components are needed.
2nd Edit: This bug appears to be fixed in Xcode 9.3.1 (available via MAS or direct download from developer.apple.com)
3rd Edit: 9.3.1 doesn't fully fix this, despite what the Release Notes say. According to the comments in my bug report, this is only be fully fixed in 9.4.
Get Xcode 9.4 Beta. It resolved my issue.
killing homed is not good solution and playground is not acting correctly anyway.
Had same issue and there was no way around it. People filed bugs as far back as April 8th.
Best solution is to download Xcode 9.4 Beta from Apple Developer Page.
This worked for me and CPU usage is low and Xcode doesn't crash on playgrounds anymore.
I also had the same issue with Xcode v 11.2.1(11B53)
It seems the issue happened after updating Mac OS and Xcode.
I found out that diagnosticd has something to do with Xcode simulators.
So I tried to Erase All Content and Settings... in Simulator menu.
Please refer to above picture.
After erasing all content and settings the issue was resolved. :D
This is a known bug, attributed by Apple to “over-enthusiastic logging by the MediaRemote subsystem”. There is no official workaround at this time.
See https://forums.developer.apple.com/message/305885
Same problem here, the only temporary solution I found was to kill 'homed', which was flooding the system with errors like
MediaRemote reply error: <error: 0x11162ed20> { count = 1, transaction: 0, voucher = 0x0, contents =
"XPCErrorDescription" => <string: 0x11162efc8> { length = 18, contents = "Connection invalid" }
}
I suppose diagnosticd, designed to report errors automatically, simply went in overdrive mode.
That's all I have for now...
What is the difference in Karaf between the commands list and la?
My understanding is that both represent the command bundle:list ("Lists all installed bundles"). That's based on the results I see when I issue either the command list --help or la --help. In both cases, the help info provided in the console describes the bundle:list command.
However, these 2 commands (list and la) in fact do not yield the same results: when I issue the list command I'm shown a list of several bundles (14 actually in my current Karaf instance), all of which are in the Active state; but when I issue the la command I get a far longer list (137), most of which are in the Active state, but some of which show as Resolved.
bundle:list gives you all bundles with a start level higher or equal to 50, while la is an alias to bundle:list -t 0 (list all).
This is done because a lot of Karaf internal bundles are having a start level lower than 50, while all bundles being installed via bundle:deploy or by placing in the deploy folder automatically have start level 80.
Also, bundles being installed by means of features are usually deployed with start level 80, unless defined otherwise.
The difference between the Active and Resolved states is because Bundles can be Active while fragments can only be Resolved.
edit
Just issuing the bundle:list command will give you the following output:
karaf#root()> list
START LEVEL 100 , List Threshold: 50
ID | State | Lvl | Version | Name
---------------------------------
As can be seen, the Threshold is 50 and given.
Update
Working on a theory, I edited LWP/Protocol/http.pm to include a sleep statement in the subroutine request:
if (!$has_content || $write_wait || $has_content > 8*1024) {
WRITE:
{
# Since this just writes out the header block it should almost
# always succeed to send the whole buffer in a single write call.
my $n = $socket->syswrite($req_buf, length($req_buf));
sleep 2; ## <----- NEW
unless (defined $n) {
...
And the get statement worked, returning a 200 OK. Much thanks for Alan Curry for help with debugging and finding this particular place in the code.
Not sure it completely answers the question, or if the solution works long term. Will have to do some more checking.
Summary:
LWP::UserAgent module using the get subroutine fails for some URLs, reporting 500 timeout.
Only some URLs fail. E.g. www.google.com fails, but www.google.se succeeds.
I have no other connection issues, all URLs are reachable with browser and through cmd programs such as ping.
Because of this problem, I cannot install modules for perl with CPAN or ActivePerl's ppm.
The problem persisted after installing another perl distribution.
Weirdly enough, using the debugger and stepping through the code makes the failing URLs succeed.
I am using a firewall, and perl is allowed to make connections. (Not relevant, since some URLs succeed)
Firewall log shows perl being allowed to connect for both failing URLs and non-failing. (See below) The log also shows sockets opening to listen, but timestamps are mismatched for failing connections.
Goal
I'm primarily looking for any solution to be able to install modules.
I'm interested in all suggestions on how to debug the problem, complete solutions not required. Any hints or tips are welcome.
Elaboration
I have been using ActivePerl v5.14 for some time. Installing modules with their Perl Package Manager ppm command and gui worked very well, but at some point stopped working, reporting a 500 timeout. The cpan shell reported the very same thing.
I have googled this problem extensively, but found nothing that relates to my problem, or helps in any way.
ActivePerl support claims it may be a proxy setting, which is ludicrous. I have lots of programs that connect to the internet that do not need proxy settings, and as far as I know, I do not need to do this. I have tried to find out what my proxy settings are, if any, but the only thing I have found is vague references such as "use the system settings", "no proxy required" and "proxy is the same as your IP".
So last night I had enough and installed strawberry perl instead, but it suffers from the same problem. I uninstalled ActivePerl afterwards.
Anyway, I have experimented with LWP modules and found that I can reproduce the errors there. It seems it is limited to certain websites, and cpan is one of them (?). I created this script for testing:
use strict;
use warnings;
use LWP::UserAgent;
use URI;
my $ua = LWP::UserAgent->new;
my $url = shift;
my $u = URI->new($url);
$ua->no_proxy('cpan.strawberryperl.com','cpan.com',$u->host);
$ua->timeout(30);
my $r = $ua->get($url);
if ($r->is_success) {
print $r->decoded_content;
} else {
die $r->status_line;
}
And then did some testing:
tx.pl http://cpan.strawberryperl.com/authors/01mailrc.txt.gz
500 read timeout at tx.pl line 23.
tx.pl http://stackoverflow.com
500 read timeout at tx.pl line 23.
tx.pl http://www.google.se
<!doctype html><html itemscope itemtype="http://schema.org/WebPage"><head><meta
http-equiv="content-type" content="text/html; charset=ISO-8859-1"><meta ...
So, google works, and www.youtube.com also works, but www.yahoo.com and search.cpan.com fails. The default timeout of 180 seconds makes this an incredibly annoying thing to debug, which is why I reduced it in my script. Needless to say, all of these URLs are reachable if I try to reach them with Firefox or ping.
ETA:
Strangely enough, running the script through the debugger, turning on trace and skipping to the end makes the previously failed connections successful.
It would seem to imply that there is some kind of hiccup, missed timing that is "fixed" when the script runs more slowly due to printing thousands of lines of trace code.
I could understand this issue as being a result of some ActivePerl module getting corrupted, but strawberry perl is using a completely different set of files, so it must be my system.
Why some sites work and some don't is baffling. I could understand that some sites like stackoverflow.com would protect themselves against potential bots, but why cpan would thwart its own package manager makes no sense.
I am using a firewall, and Perl has been allowed to make connections. My system is a rather old installation of Windows XP (~5 years). While running dual boot with Ubuntu I've never encountered this problem, which is another clue that it is not something to do with proxies.
I am well and truly stumped. If anyone could help me debug this, I would be very grateful.
The CPAN shell error messages below. The funny thing is, it says it tries to use the ftp as a last resort, but I just discovered that the ftp command has not been allowed by my firewall, and if it was used, it should have asked me for permission.
Fetching with LWP:
http://cpan.strawberryperl.com/authors/01mailrc.txt.gz
LWP failed with code[500] message[read timeout]
Warning: no success downloading 'D:\strawberry\cpan\sources\authors\01mailrc.txt
.gz.tmp1252'. Giving up on it.
Fetching with LWP:
http://www.cpan.org/authors/01mailrc.txt.gz
LWP failed with code[500] message[read timeout]
Warning: no success downloading 'D:\strawberry\cpan\sources\authors\01mailrc.txt
.gz.tmp1252'. Giving up on it.
Warning: no success downloading 'D:\strawberry\cpan\sources\authors\01mailrc.txt
.gz.tmp1252'. Giving up on it.
As a last resort we now switch to the external ftp command 'C:\WINDOWS\system32\
ftp.EXE'
to get 'D:\strawberry\cpan\sources\authors\01mailrc.txt.gz.tmp1252'.
Doing so often leads to problems that are hard to diagnose.
If you're the victim of such problems, please consider unsetting the
ftp config variable with
o conf ftp ""
o conf commit
Please check, if the URLs I found in your configuration file
(http://cpan.strawberryperl.com/, http://www.cpan.org/) are valid. The
urllist can be edited. E.g. with 'o conf urllist push ftp://myurl/'
Could not fetch authors/01mailrc.txt.gz
Firewall log for trying to fetch non-failing URL (www.google.se) and failing (stackoverflow.com):
2012-06-27T18:34:04+01:00,info,appl control,C:\WINDOWS\system32\svchost.exe,allow,listen,17,0.0.0.0,56564
2012-06-27T18:34:04+01:00,info,appl control,C:\WINDOWS\system32\svchost.exe,allow,send,17,195.54.122.198,53
2012-06-27T18:34:13+01:00,info,appl control,D:\strawberry\perl\bin\perl.exe,allow,connect out,6,64.34.119.12,80
2012-06-27T18:34:13+01:00,info,appl control,D:\strawberry\perl\bin\perl.exe,allow,connect out,6,64.34.119.12,80
2012-06-27T18:34:21+01:00,info,appl control,C:\Program\Mozilla Firefox\firefox.exe,allow,connect out,6,74.86.70.106,80
2012-06-27T18:34:28+01:00,info,appl control,C:\Program\Mozilla Firefox\firefox.exe,allow,connect out,6,64.34.119.12,80
2012-06-27T18:34:30+01:00,info,appl control,C:\WINDOWS\system32\svchost.exe,allow,listen,17,0.0.0.0,56664
2012-06-27T18:34:30+01:00,info,appl control,C:\WINDOWS\system32\svchost.exe,allow,send,17,195.54.122.198,53
2012-06-27T18:34:30+01:00,info,appl control,D:\strawberry\perl\bin\perl.exe,allow,connect out,6,74.125.143.94,80
2012-06-27T18:34:30+01:00,info,appl control,D:\strawberry\perl\bin\perl.exe,allow,connect out,6,74.125.143.94,80
2012-06-27T18:35:14+01:00,info,appl control,C:\Program\Mozilla Firefox\firefox.exe,allow,connect out,6,64.34.119.12,80
2012-06-27T18:35:21+01:00,info,appl control,C:\Program\Mozilla Firefox\firefox.exe,allow,connect out,6,74.86.70.106,80
2012-06-27T18:36:21+01:00,info,appl control,C:\Program\Mozilla Firefox\firefox.exe,allow,connect out,6,74.86.70.106,80
2012-06-27T18:37:04+01:00,info,appl control,C:\WINDOWS\system32\svchost.exe,allow,listen,17,0.0.0.0,61215
2012-06-27T18:37:04+01:00,info,appl control,C:\WINDOWS\system32\svchost.exe,allow,send,17,195.54.122.198,53
2012-06-27T18:37:07+01:00,info,appl control,D:\strawberry\perl\bin\perl.exe,allow,connect out,6,64.34.119.12,80
2012-06-27T18:37:07+01:00,info,appl control,D:\strawberry\perl\bin\perl.exe,allow,connect out,6,64.34.119.12,80
This might not be a complete solution to your problem. But here it is anyway:
From your "detailed" problem description it looks like it's a problem with your desktop/laptop. Even though your firewall allows connections to websites as you mentioned, "FTP" might not be allowed by the Windows internal firewall.
Usually, ports 20 (FTP command port) and 21 (FTP data port) should have been added to the firewall exceptions (In Windows - Start → Settings → Control Panel → Click on Security Center → Firewall → Exceptions (tab) → Add ports. You can try adding ports 20 and 21 to the exceptions.
However, if you are connected to a router, you may have to port forward ports 20 and 21. However, these ports are forwarded by default, or if you are in a corporate VPN then it's a whole different story. Corporate VPNs, mostly restrict port 21 explicitly however allow port 22 (which is a secured version of port 21, for SFTP). Under such circumstances you may want to use ftp_proxy.
Alternatively (if you don't want to add port 20 and 21 to exception), you can go to the cpan prompt and use an ftp_proxy by:
cpan> o conf ftp_proxy http://your.ftpproxy.com
and then issue the install <module> command. Or you can update your ../CPAN/config.pm file to make permanent changes to the ftp_proxy parameter.
Well, these may be the traditional solutions which you probably already tried. The next step would be to try set the FTP_PASSIVE mode to 1. By default the libnetcfg configuration for this is set to 0. To change this, find the libnetcfg.bat file (it should be somewhere C:\Perl\bin). Open the file in an editor and replace
ftp_int_passive 0
with
ftp_int_passive 1
This is the Windows batch file that runs once CPAN is invoked to set the environment variables. Under a UNIX/Linux-like architecture it's found as libnet.cfg and environment variable FTP_PASSIVE, like
$set | grep FTP_PASSIVE
FTP_PASSIVE=0
so to set just EXPORT FTP_PASSIVE=1.
These might be a few of the very many ways of debugging this. Honestly, there is no point fiddling around the library code as they well work on every other machine, usually 95% of 01mailrc.txt.gz.tmp1252 download issues are due to network/OS/firewall issues, but if you want to expand your Perl knowledge of LWP you can. In fact, you should also be looking at CPAN::FTP::netrc. Best of luck...
EDIT: updated this question with latest information...
I'm having issues running back-to-back "features:uninstall" commands for dependent features. OSGi responds back with "State change in progress...", but by accepting other requests, we run into issues.
Strangely, this results in successful feature uninstalls, but unsuccessful bundle uninstalls. We are addressing this by trying to order uninstall requests appropriately and adding a delay between steps, but I'm hoping for a more robust solution.
As suggested, I also tried adding "osgi:refresh" in between steps...same behavior. Is there another way to detect that "Refresh Packages" is still running to delay subsequent requests, etc?
Here are the details...
karaf#root> features:uninstall PolicyUtil
karaf#root> features:uninstall Policy1
karaf#root> features:uninstall Policy2
State change in progress for bundle "file:/policy2.jar" by thread "Refresh Packages".
karaf#root> features:uninstall Policy3
State change in progress for bundle "file:/policy3.jar" by thread "Refresh Packages".
karaf#root> features:uninstall Policy4
karaf#root> features:uninstall Enabler1
State change in progress for bundle "file:/enabler1.jar" by thread "Refresh Packages".
karaf#root> features:uninstall Enabler2
State change in progress for bundle "file:/enabler2.jar" by thread "Refresh Packages".
afterwards...we end up with features uninstalled (correct), but some bundles still installed (incorrect)
osgi:list
[ 277] [Installed ] [ ] [ ] [ 60] Policy2
[ 278] [Installed ] [ ] [ ] [ 60] Policy3
[ 280] [Installed ] [ ] [ ] [ 60] Enabler1
[ 281] [Installed ] [ ] [ ] [ 60] Enabler2
features:list
[uninstalled] [1.0 ] PolicyUtil repo-0
[uninstalled] [1.0 ] Policy1 repo-0
[uninstalled] [1.0 ] Policy2 repo-0
[uninstalled] [1.0 ] Policy3 repo-0
[uninstalled] [1.0 ] Enabler1 repo-0
[uninstalled] [1.0 ] Enabler2 repo-0
I'm not sure what kind of exception you will get, but you should be aware of one thing: when you uninstall a bundle using a shell command like osgi:uninstall, you effectively call Bundle.uninstall(). As you can read in the Javadoc there, this is not the entire story.
The framework favors operations that have minimal impact on the rest of the framework, so it can uninstall a bundle without removing all related packages. If you really want to remove all of them, you should use a osgi:refresh command. For more information on this, see the Felix FAQ.
The best advice I can give is to not issue multiple uninstall requests that can cross each other. If you want to remove a set of bundles, I would fire off non-crossing uninstall() requests, followed by a single refreshPackages(). Also, I would not mix bundle management using the 'regular' console and Karaf in a single system.
You could also consider using an external manager for installing and removing bundles. If you want remote management, you could go for Apache ACE (disclosure: I'm an Apache ACE committer).
Oor ... you can simple uninstall your app with this command:
karaf 2.2.x:
osgi:uninstall --force yourapp-feature/0.0.1.SNAPSHOT
Alright, I've been digging into this and I think I understand the issue and the options...thanks for the responses.
When "features:uninstall [name]" is executed, it calls bundle.uninstall(), then refreshPackages() for each bundle in the features. Then, after all bundles are uninstalled, it calls refreshPackages() for all bundles. The issue is that refreshPackages() is asynchronous (per the OSGi spec) and leaves bundles in a resolving state. Subsequent requests to uninstall resolving features/bundles fail to complete as expected.
If there is sufficient delay in between uninstalls or if a later uninstall is executed (after the refreshPackages() has completed)...everything works as expected.
Options...
order dependent features/bundles during uninstallation (difficult to control)
put a delay in between uninstall commands (not exact)
verify expected features/bundles are uninstalled (or continue waiting)
listen for FrameworkEvent.PACKAGES_REFRESHED events (complex and not guaranteed because events are container wide, see this example)
modify Karaf/Felix to support an option for synchronously refreshing packages (see this issue/resolution for Karaf 2.1.3)
In my experience this happens when a resource of a bundle is still referenced or used by another bundle. In this case the framework is not able to remove the bundle and the whole jar file is still processed by the VM.
Have a look and be sure that all references are removed. A common mistake is also still running thread in one of the objects instantiated in the bundle. This also counts as a resource still in use ad which cannot be removed.
In my case i have uninstalled the feature and noticed the hanging bundle numbers and then shutdown karaf (3.x). Then i have removed the subfolders of folder [karaf-install]/data/cache/[hanging-bundle-number].
Now i restart karaf and the bundle wars not shown in the bundle:list.