“未找到命令：grep”在卡拉夫控制台中
我对 Servicemix 版本 Fuse ESB 4.4.1 有奇怪的问题。
有时，部分命令将无法加载并且不可用。通常这种情况发生在我经常使用的命令 grep 上。这看起来如下：
karaf@root>列表 | grep 弹簧
未找到命令：grep
这似乎是随机的，重新启动通常会有所帮助。在 Fuse ESB 的早期版本中，有时会发生这种情况，但非常罕见，现在它经常发生。有人可以帮忙吗，是什么原因造成的？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
也许完全不相关，但我在 Karaf 及其依赖项中遇到了许多启动时竞争条件。最重要的是，我提交的这个：
https://issues.apache.org/jira/浏览/KARAF-910
“FeatureService 和 ConfigAdmin 之间争夺 mvn: URL 解析？”
仅当您对 pax-url-mvn 有一些非标准设置时，该特定缺陷才会显现出来，但这是 configadmin 异步应用设置的一般问题的症状，因此 configadmin 线程比主 OSGi 包更快或更慢很重要- 启动线程。
我没有看到任何与该竞赛相关的 Karaf Command 问题，但我的问题表面上相似，因为某些捆绑服务随机不启动。
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.
“grep”命令有一个全名 - shell:grep。您可以尝试查看是否已使用相同的短（不合格）名称安装了另一个命令，并且它变得混乱。
另一种可能性是提供 grep 服务的捆绑包已停止（可能是意外）。
osgi:list -t 0 -s
将按符号名称向您显示所有捆绑包的列表，其中包括这个：（数字可能不同）：
至于为什么该捆绑包被停止 - 也许是某事（或某人）明确停止它吗？或者它被意外停止了？
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):
As for why that bundle is being stopped -- maybe something (or someone) is explicitly stopping it? Or it's being stopped by accident?