OSGi feature uninstall works, but bundles are still installed - osgi

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.

Related

Run an exe file on a Mac with Wineskin (VseeFace Application)

I really hope that someone could help me out with my problem.
I want to start an exe File (VSeeFace - see https://www.vseeface.icu for more information) on my Mac with wineskin. VseeFace is an application for Vtubing.
The application starts normally via Wineskin, but as soon as I try to open my avatar (a .vrm file), the software stops and I don't know why. I have searched everywhere and found nothing about my problem, but perhaps that is also due to my limited knowledge of development skills.
Can anyone help me please?
My Mac:
MacOS Monterey Version 12.4
Radeon Pro 575X 4 GB
My Wineskin Setup:
Wrapper Version Wineskin 2.9.1.5
Engine WS11WineCX64Bit22.0.1-1
Config Utility - Windows-Version 8
VseeFace Software – https://www.vseeface.icu/#download
They also describe how it will work on Linux or maybe Mac,
https://www.vseeface.icu/#running-on-linux-and-maybe-mac
For the Facetracking I run OpenSeeFace (but that seemed to work, I could see the green light of the iMac camera, but I couldn't test it because of my software problem).
I mean I could run the application but on the most important Screen it stops working.
In the debug.log file I noticed the following messages:
0024:err:shell:HCR_GetFolderAttributes should be called for simple PIDL's only!
0024:fixme:exec:SHELL_execute flags ignored: 0x0000000c
0118:err:module:import_dll Library dsound.dll (which is needed by L"C:\windows\system32\devenum.dll") not found
0118:trace:loaddll:build_module Loaded L"C:\windows\system32\msdmo.dll" at 000000034ABC0000: builtin
0118:err:ole:apartment_add_dll couldn't load in-process dll L"C:\windows\system32\devenum.dll"
0118:err:ole:com_get_class_object no class object {62be5d10-60eb-11d0-bd3b-00a0c911ce86} could be created for context 0x1
0118:err:module:import_dll Library dsound.dll (which is needed by L"C:\windows\system32\devenum.dll") not found
0118:err:ole:apartment_add_dll couldn't load in-process dll L"C:\windows\system32\devenum.dll"
0118:err:ole:com_get_class_object no class object {62be5d10-60eb-11d0-bd3b-00a0c911ce86} could be created for context 0x1
0118:err:ole:apartment_add_dll couldn't find function DllGetClassObject in L"C:\windows\system32\devenum.dll"
0118:err:ole:com_get_class_object no class object {62be5d10-60eb-11d0-bd3b-00a0c911ce86} could be created for context 0x1
0118:err:ole:com_get_class_object no class object {62be5d10-60eb-11d0-bd3b-00a0c911ce86} could be created for context 0x1
0118:trace:loaddll:build_module Loaded L"C:\windows\system32\Avrt.dll" at 00000002F2930000: builtin
0118:trace:loaddll:build_module Loaded L"C:\VSeeFace\VSeeFace_Data\Plugins\x86_64\LeapCV4.dll" at 000000010A220000: native
0118:trace:loaddll:build_module Loaded L"C:\windows\system32\VCRUNTIME140_1.dll" at 00000002F7F20000: builtin
0118:err:module:import_dll Loading library MSVCP140_2.dll (which is needed by L"C:\VSeeFace\VSeeFace_Data\Plugins\x86_64\LeapCV5.dll") failed (error c000007b).
0118:trace:loaddll:build_module Loaded L"C:\VSeeFace\VSeeFace_Data\Plugins\x86_64\CONCRT140.dll" at 0000000104CA0000: native
0118:err:module:import_dll Loading library MSVCP140_2.dll (which is needed by L"C:\VSeeFace\VSeeFace_Data\Plugins\x86_64\LeapCV5.dll") failed (error c000007b).
[mvk-info] Created 2 swapchain images with initial size (1280, 720) and contents scale 1.0 for screen Integriertes Retina-Display.
[mvk-error] VK_ERROR_INITIALIZATION_FAILED: Render pipeline compile failed (Error code 2):
Vertex attribute v4(4) of type int4 cannot be read using MTLAttributeFormatUInt4.
0118:trace:loaddll:build_module Loaded L"C:\VSeeFace\UnityPlayer.dll" at 0000000180000000: native
0118:fixme:thread:get_thread_times not implemented on this platform
0118:trace:loaddll:build_module Loaded L"C:\windows\system32\mmdevapi.dll" at 0000000336850000: builtin
0118:trace:loaddll:build_module Loaded L"C:\windows\system32\winecoreaudio.drv" at 00000001C92D0000: builtin
0118:fixme:coreaudio:ca_channel_layout_to_channel_mask Unhandled channel 0xffffffff
0
01b0:fixme:kernelbase:AppPolicyGetThreadInitializationType FFFFFFFFFFFFFFFA, 0000000066D6FE10
01b0:trace:loaddll:build_module Loaded L"C:\windows\system32\avrt.dll" at 00000002F2930000: builtin
01b0:fixme:avrt:AvSetMmThreadCharacteristicsW (L"Audio",0000000066D6FDB8): stub
01b0:trace:loaddll:free_modref Unloaded module L"C:\windows\system32\avrt.dll" : builtin
***If needed I could post the complete log file. ***
I have installed the dlls and they are in all the folders. I have also tried the installation via Winetricks, where it displays the following message:
Executing mkdir -p /Applications/Wineskin/VSeeFace.app/Contents/SharedSupport
warning: You are using a 64-bit WINEPREFIX. Note that many verbs only install 32-bit versions of packages. If you encounter problems, please retest in a clean 32-bit WINEPREFIX before reporting a bug.
Using winetricks 20220411-next - sha256sum: 846f79cac49697fd818f06a6aebf36ca408661f89b97633e9872025b33bc0e7b with wine-7.7 (WineskinCX 22.0.1) and WINEARCH=win64
Unknown arg UnityPlayer.dll
Usage: Applications/Wineskin/VSeeFace.app/Wineskin.app/Contents/Resources/winetricks [options] [command|verb|path-to-verb] ...
Executes given verbs. Each verb installs an application or changes a setting.
Options:
--country=CC Set country code to CC and don't detect your IP address
-f, --force Don't check whether packages were already installed
--gui Show gui diagnostics even when driven by commandline
--gui=OPT Set OPT to kdialog or zenity to override GUI engine
--isolate Install each app or game in its own bottle (WINEPREFIX)
--self-update Update this application to the last version
--update-rollback Rollback the last self update
-k, --keep_isos Cache isos (allows later installation without disc)
--no-clean Don't delete temp directories (useful during debugging)
-q, --unattended Don't ask any questions, just install automatically
-r, --ddrescue Retry hard when caching scratched discs
-t --torify Run downloads under torify, if available
--verify Run (automated) GUI tests for verbs, if available
-v, --verbose Echo all commands as they are executed
-h, --help Display this message and exit
-V, --version Display version and exit
Commands:
list list categories
list-all list all categories and their verbs
apps list list verbs in category 'applications'
benchmarks list list verbs in category 'benchmarks'
dlls list list verbs in category 'dlls'
fonts list list verbs in category 'fonts'
games list list verbs in category 'games'
settings list list verbs in category 'settings'
list-cached list cached-and-ready-to-install verbs
list-download list verbs which download automatically
list-manual-download list verbs which download with some help from the user
list-installed list already-installed verbs
arch=32|64 create wineprefix with 32 or 64 bit, this option must be
given before prefix=foobar and will not work in case of
the default wineprefix.
prefix=foobar select WINEPREFIX=/Users/myusername/.local/share/wineprefixes/foobar
annihilate Delete ALL DATA AND APPLICATIONS INSIDE THIS WINEPREFIX
Winetricks Commands Finished!!

How do I change window managers with Yocto Project tools?

My Intent
I have an image generated by BitBake on which I'm interested in changing the window manager to metacity or maybe something similar.
My Process
I've added require recipes-graphics/images/core-image-x11.bb into my core recipe, which provides a simple Matchbox terminal window but seemingly no other functionality. If I add matchbox-desktop and matchbox-session-sato, it adds a bit more usability but not what I'm looking for.
I've included the default package from the metacity_2.34.13.bb recipe from the meta-gnome layer from the OpenEmbedded Metadata Index in the IMAGE_INSTALL variable of my core image. This installs several components including a metacity command in /usr/bin. If I run that command, I get the following message:
GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications
(metacity:1124): GLib-GIO-ERROR **: Settings schema 'org.gnome.metacity' is not installed
Trace/breakpoint trap
I've navigated to /usr/share/glib-2.0/schemas and run glib-compile-schemas ., then run:
startx
metacity --replace
again. Now, the output is:
Window manager error: Unable to open X display
I haven't found a clear solution to this error which applies to my specific situation.
Update (2/29):
I may have now found a solution to this error, using these commands:
X&
export DISPLAY=:0
metacity&
At this point, I seem to be running something on one of my VTs. I can run demos like glxgears in that VT (glxgears is included in the mesa-demos recipe), but I don't know how to actually create a usable environment.
My question(s)
I'm not using much from meta-openembedded/meta-gnome (just metacity) or meta/recipes-gnome (adwaita-icon-theme, gnome-desktop3, gsettings-desktop-schemas and gtk+3), so am I missing some recipe which automates the addition of metacity?
(if not Question 1) How can I solve the error Window manager error: Unable to open X display?
The x11-common recipe adds a X session script that will run /usr/bin/x-session-manager: that is responsible for starting your desktop environment.
The way to implement a new session/DE in OE-Core is to use update-alternatives for "x-session-manager": see the matchbox-session recipe for the default implementation and mini-x-session recipe for an alternative.
mini-x-session might be modifiable for your needs so you don't need to write a new one: A /etc/mini_x/session file like this might do the trick:
# start any apps here, e.g. "my-desktop &"
exec metacity
Going from this (a running window manager) to "usable environment" might still be lots and lots of work, depending on your definition of usable.

OSGi: unable to find UserAdmin in Apache Karaf

I am trying to install and start the Apache Felix implementation of the OSGi UserAdmin interface in Karaf 2.3.3.
karaf#root> install mvn:org.apache.felix/org.apache.felix.useradmin/1.0.3
However, the bundle never gets resolved and I get the following error on start:
Unable to start bundle 89: Activator start error in bundle org.apache.felix.useradmin [89].
[...]
Caused by: java.lang.NoClassDefFoundError: org.osgi.service.useradmin.UserAdminListener
at org.apache.felix.useradmin.osgi.UserAdminListenerListHelper.class$(UserAdminListenerListHelper.java:38)
at org.apache.felix.useradmin.osgi.UserAdminListenerListHelper.<init>(UserAdminListenerListHelper.java:38)
at org.apache.felix.useradmin.osgi.Activator.createServiceContext(Activator.java:68)
at org.apache.felix.useradmin.osgi.Activator.start(Activator.java:37)
at org.apache.felix.framework.util.SecureAction$Actions.run(SecureAction.java:1605)
at java.security.AccessController.doPrivileged(Native Method)[:1.7.0_51]
at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:636)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1977)
... 16 more
As I read in this thread from the Karaf mailing list, Karaf already embeds the OSGi Compendium API but doesn't export all packages by default. I changed the config.properties file to explicitly export the UserAdmin package:
org.osgi.framework.system.packages= \
[...]
org.osgi.service.permissionadmin;uses:="org.osgi.framework";version="1.1", \
org.osgi.service.useradmin;uses:="org.osgi.framework";version="1.1", \
[...]
The package org.osgi.service.useradmin seems to be exported by Karaf, as I can see upon running packages:exports.
I kept getting the error until I removed the line from the config file and deployed the OSGi Compendium API bundle as suggested in this other thread.
However, embedding the complete Compendium API seems somewhat overkill to me (though I may be wrong). And I now have 4 bundles exporting the UserAdmin package:
karaf#root> packages:exports | grep useradmin
0 # org.osgi.service.useradmin; version=1.1.0
20 org.osgi.jmx.service.useradmin; version=1.1.0
82 org.osgi.service.useradmin; version=1.1.0 --> OSGi Compendium osgi.cmpn (5.0.0.201305092017)
89 org.apache.felix.useradmin; version=1.0.0 --> Apache Felix User Admin Service (1.0.3)
Do you know of a better/simpler way to achieve this?
karaf#root> packages:exports | grep useradmin
0 # org.osgi.service.useradmin; version=1.1.0
20 org.osgi.jmx.service.useradmin; version=1.1.0
82 org.osgi.service.useradmin; version=1.1.0 --> OSGi Compendium osgi.cmpn (5.0.0.201305092017)
89 org.apache.felix.useradmin; version=1.0.0 --> Apache Felix User Admin Service (1.0.3)
That first bundle you listed, 0, that is exporting useradmin, I suspect isn't actually exporting anything. The second one is exporting a completely unrelated package. The third one is exporting the actual useradmin API. And the fourth one is exporting the apache felix specific classes.
Karaf doesn't actually contain the useradmin package anywhere in the standard download.
apache-karaf-2.3.3 sartrip -> gfind -iname \*jar | parallel unzip -l {} | grep userad
0 01-23-13 14:59 org/osgi/jmx/service/useradmin/
4462 01-23-13 14:59 org/osgi/jmx/service/useradmin/UserAdminMBean.class
822 01-23-13 14:59 org/osgi/jmx/service/useradmin/packageinfo
0 02-08-13 11:24 org/apache/aries/jmx/useradmin/
12187 02-08-13 11:24 org/apache/aries/jmx/useradmin/UserAdmin.class
1828 02-08-13 11:24 org/apache/aries/jmx/useradmin/UserAdminMBeanHandler.class
That means you must install the a bundle containing the useradmin API, either by installing the OSGI compendium API bundle or building your own JAR containing just the parts you want (org.osgi.service.useradmin).
EDIT:
I'll also point out that the not-yet-released version of apache felix useradmin will contain the org.osgi.service.useradmin (as it should!) meaning eventually your dependency on the compendium API jar will go away. https://github.com/apache/felix/blob/trunk/useradmin/useradmin/pom.xml#L81

LWP connect issues despite fresh install

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...

"Command not found: grep" in karaf console

I have strange problem with Servicemix version Fuse ESB 4.4.1.
Sometimes the part of the commands will not load and be not available. Usually this happens with quite often used by me command, grep. This looks as following:
karaf#root> list | grep spring
Command not found: grep
It seems to be random, restart usually helps. With previous versions of Fuse ESB it happened sometimes, but quite rare, now it happens quite often. Can someone help, what is causing the problem?
Perhaps completely unrelated, but I've encountered a number of boot-time race conditions in Karaf and its dependencies. Most importantly, this one that I filed:
https://issues.apache.org/jira/browse/KARAF-910
"Race between FeatureService and ConfigAdmin for resolving mvn: URLs?"
That particular defect only manifests if you have some non-standard settings for pax-url-mvn, but it's a symptom of the general problem that configadmin applies settings asynchronously, so it matters if the configadmin thread is faster or slower than the main OSGi bundle-starting thread.
I have not seen any Karaf Command problems related to that race, but my problem is superficially similar in that some bundle services randomly don't start.
The 'grep' command has a full name - shell:grep. You might try that to see if e.g. another command has been installed with the same short (unqualified) name and it's getting confused.
The other possibility is that the bundle that provides the grep service has stopped, possibly by accident.
osgi:list -t 0 -s
will show you a list of all the bundles by symbolic name, which includes this one: (the number may be different):
[ 18] [Active ] [Created ] [ 30] org.apache.karaf.shell.commands (2.2.3)
karaf#root> osgi:stop 18
You are about to access system bundle 18. Do you wish to continue (yes/no): yes
karaf#root> help | grep grep
Command not found: grep
karaf#root> osgi:start 18
You are about to access system bundle 18. Do you wish to continue (yes/no): yes
karaf#root> help | grep grep
shell:grep
As for why that bundle is being stopped -- maybe something (or someone) is explicitly stopping it? Or it's being stopped by accident?

Resources