starting FedoOne server - linux

I have followed the installation instructions as shown here
to install the FedOne server,I am using openfire as the xmpp server and I have managed to run the server and the client as supposed.
After a while I thought of deploying an agent and wanted to start the FedOne server again but the run-server.sh fails complaining
`2010-09-20 12:25:30.425:WARN::FAILED SelectChannelConnector#localhost:9879: java.net.BindException: Address already in use
2010-09-20 12:25:30.425:DBUG::EXCEPTION
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:137)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:77)
at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:209)
at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:289)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55)
at org.eclipse.jetty.server.Server.doStart(Server.java:253)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55)
at org.waveprotocol.wave.examples.fedone.rpc.ServerRpcProvider.startWebSocketServer(ServerRpcProvider.java:328)
at org.waveprotocol.wave.examples.fedone.ServerMain.run(ServerMain.java:74)
at org.waveprotocol.wave.examples.fedone.ServerMain.main(ServerMain.java:48)
org.eclipse.jetty.server.Server#9300cc STOPPED
+-ServletContextHandler#1469658#1469658/,file:/home/maxsap/Documents/progrs/FedOne/wave-protocol/war/ started
+-ServletHandler#1304043 started
+-[/wave]=>org.waveprotocol.wave.examples.fedone.rpc.WaveClientServlet-7654146{}
+-[/socket]=>org.waveprotocol.wave.examples.fedone.rpc.ServerRpcProvider$WaveWebSocketServlet-33239569{bufferSize=1048576}
+-[/static/]=>org.eclipse.jetty.servlet.DefaultServlet-21909041{}
+-[/webclient/]=>org.eclipse.jetty.servlet.DefaultServlet-21909041{}
+-[/]=>org.waveprotocol.wave.examples.fedone.rpc.WaveClientServlet-9975050{}
+-[/attachment/*]=>org.waveprotocol.wave.examples.fedone.rpc.AttachmentServlet-33355664{}
2010-09-20 12:25:30.426:WARN::FAILED org.eclipse.jetty.server.Server#9300cc: java.net.BindException: Address already in use
2010-09-20 12:25:30.426:DBUG::EXCEPTION
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:137)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:77)
at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:209)
at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:289)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55)
at org.eclipse.jetty.server.Server.doStart(Server.java:253)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55)
at org.waveprotocol.wave.examples.fedone.rpc.ServerRpcProvider.startWebSocketServer(ServerRpcProvider.java:328)
at org.waveprotocol.wave.examples.fedone.ServerMain.run(ServerMain.java:74)
at org.waveprotocol.wave.examples.fedone.ServerMain.main(ServerMain.java:48)
Sep 20, 2010 12:25:30 PM org.waveprotocol.wave.examples.fedone.rpc.ServerRpcProvider startWebSocketServer
SEVERE: Fatal error starting http server.
java.net.BindException: Address already in use
at sun.nio.ch.Net.bind(Native Method)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:137)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:77)
at org.eclipse.jetty.server.nio.SelectChannelConnector.open(SelectChannelConnector.java:209)
at org.eclipse.jetty.server.nio.SelectChannelConnector.doStart(SelectChannelConnector.java:289)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55)
at org.eclipse.jetty.server.Server.doStart(Server.java:253)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:55)
at org.waveprotocol.wave.examples.fedone.rpc.ServerRpcProvider.startWebSocketServer(ServerRpcProvider.java:328)
at org.waveprotocol.wave.examples.fedone.ServerMain.run(ServerMain.java:74)
at org.waveprotocol.wave.examples.fedone.ServerMain.main(ServerMain.java:48)`
by default the server runs at the port 9898 as shown on the above output,I have tried using netstat and lsof to find what service is using that port but no one does!
also tried to change the port from the configuration but also no luck!
Has anyone had the same problem? if yes have he/she solved it? and how
also is there any linux command that I can query the port and tell me who is using that service?

So it terns out that the server runs after all but for some reason it complains about the bind exception.
The correct way to look for the service given a port is either the one on the comment above or using fuser <protocol> <port>.

Related

Just installed mongodb cant connect to server on Ubuntu 22.04

I just completed an installation of mongodb in my computer and, after starting and enabling it I keep getting the same error:
MongoDB shell version v4.2.23
connecting to: mongodb://127.0.0.1:27017/?compressors=disabled&gssapiServiceName=mongodb
2022-11-10T16:25:32.787+0100 E QUERY [js] Error: couldn't connect to server 127.0.0.1:27017, connection attempt failed: SocketException: Error connecting to 127.0.0.1:27017 :: caused by :: Connection refused :
connect#src/mongo/shell/mongo.js:353:17
#(connect):2:6
2022-11-10T16:25:32.788+0100 F - [main] exception: connect failed
2022-11-10T16:25:32.788+0100 E - [main] exiting with code 1
I uninstalled and installed multiple times and tried solutions that worked for other people in similar posts but I can not make it work.
I have a feeling it have something to do with the port it is looking for (27017) but I do not know how to check if that is the problem and, if so, how to fix it.
Thanks!
Here are a few things to consider:
Check if the MongoDB process is running (you can verify using ps, netstat (check listen port) command in the server.
See if your MongoDB service runs locally. That is because by default, the listen address of MongoDB is localhost/loopback.
Check if the firewall is running and you have allowed the port.
Verify if you are able to use telnet to command the port 27017 from the application server.

WebSphere v7.0 doesn't start CREATE_LISTENER_FAILED_4

I work with WebSphere v7.0. When I tried to start the server, I get the following error on the console.
[26/08/19 10:02:35:224 CEST] 00000000 WsServerImpl E WSVR0009E: Se ha producido un error durante el inicio
com.ibm.ws.exception.RuntimeError: org.omg.CORBA.INTERNAL: CREATE_LISTENER_FAILED_4 vmcid: 0x49421000 minor code: 56 completed: No
at com.ibm.ws.runtime.component.ORBImpl.start(ORBImpl.java:439)
at com.ibm.ws.runtime.component.ContainerHelper.startComponents(ContainerHelper.java:538)
at com.ibm.ws.runtime.component.ContainerImpl.startComponents(ContainerImpl.java:627)
at com.ibm.ws.runtime.component.ContainerImpl.start(ContainerImpl.java:618)
at com.ibm.ws.runtime.component.ServerImpl.start(ServerImpl.java:502)
at com.ibm.ws.runtime.WsServerImpl.bootServerContainer(WsServerImpl.java:298)
at com.ibm.ws.runtime.WsServerImpl.start(WsServerImpl.java:214)
at com.ibm.ws.runtime.WsServerImpl.main(WsServerImpl.java:666)
at com.ibm.ws.runtime.WsServer.main(WsServer.java:59)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at com.ibm.wsspi.bootstrap.WSLauncher.launchMain(WSLauncher.java:213)
at com.ibm.wsspi.bootstrap.WSLauncher.main(WSLauncher.java:93)
at com.ibm.wsspi.bootstrap.WSLauncher.run(WSLauncher.java:74)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:340)
at org.eclipse.core.launcher.Main.basicRun(Main.java:282)
at org.eclipse.core.launcher.Main.run(Main.java:981)
at com.ibm.wsspi.bootstrap.WSPreLauncher.launchEclipse(WSPreLauncher.java:341)
at com.ibm.wsspi.bootstrap.WSPreLauncher.main(WSPreLauncher.java:111)
Caused by: org.omg.CORBA.INTERNAL: CREATE_LISTENER_FAILED_4 vmcid: 0x49421000 minor code: 56 completed: No
at com.ibm.ws.orbimpl.transport.WSTransport.createListener(WSTransport.java:867)
at com.ibm.ws.orbimpl.transport.WSTransport.initTransports(WSTransport.java:605)
at com.ibm.rmi.iiop.TransportManager.initTransports(TransportManager.java:157)
at com.ibm.rmi.corba.ORB.set_parameters(ORB.java:1303)
at com.ibm.CORBA.iiop.ORB.set_parameters(ORB.java:1690)
at org.omg.CORBA.ORB.init(ORB.java:364)
at com.ibm.ws.orb.GlobalORBFactory.init(GlobalORBFactory.java:92)
at com.ibm.ejs.oa.EJSORBImpl.initializeORB(EJSORBImpl.java:179)
at com.ibm.ejs.oa.EJSServerORBImpl.<init>(EJSServerORBImpl.java:102)
at com.ibm.ejs.oa.EJSORB.init(EJSORB.java:55)
at com.ibm.ws.runtime.component.ORBImpl.start(ORBImpl.java:432)
... 29 more
[26/08/19 10:02:35:135 CEST] 00000000 FfdcProvider W com.ibm.ws.ffdc.impl.FfdcProvid
I checked the port BOOTSTRAP_ADDRESS in the file serverindex.xml
<specialEndpoints xmi:id="NamedEndPoint_1183122129640" endPointName="BOOTSTRAP_ADDRESS">
<endPoint xmi:id="EndPoint_1183122129640" host="F120000.cargas02.sir" port="2809"/>
</specialEndpoints>
The output command netstat -ano is
TCP 0.0.0.0:2809 0.0.0.0:0 LISTENING 4072
How can I fix this error?
Usually an ORB Listener Thread creation failure occurs because either:
Another process is already listening on the port in question (in this case 2809).
The ephemeral port range has been expanded on the OS such that the WebSphere server port ranges (2800 - ~10000) are now included in that range, increasing the possibility of a WAS server port number being assigned to another process as an ephemeral port.
For scenario #1: use netstat -ano or lsof -i :<port#> commands and search for the port to find the process using the port. If a conflicting process is found, change the config/port ussage of that process. Or edit the WebSphere serverindex.xml file in dmgr-profile-root/config/cells/cellName/nodes/nodename (make sure to take a backup beforehand). Change the 2809 port to another port not in use. Save and sync the changes.
For scenario #2: Check the ephemeral port range on the server box (internet search based on the OS will give specific instructions for this). Make sure the low end of the port range is sufficiently greater than the highest WebSphere server ports found in the serverindex.xml file.
Finally, it's also possible the WebSphere server did not properly shutdown and close all ports from its previous run. An OS reboot may be needed to release the port(s).

CArtAgO java.rmi.ConnectException Connection refused in a distributed environment

I am trying to connect remotely to a JaCaMo application by CArtAgO infrastructure.
In the server my jcm file is like this:
mas testsvr {
agent bob
workspace world
platform: cartago(infrastructure)
class-path: lib // java class path
asl-path: src/agt, src/agt/inc // agent source path
}
And a client application is like this:
mas testclient {
agent alice
platform: cartago()
node n1 running # 10.0.0.14
class-path: lib // java class path
asl-path: src/agt, src/agt/inc // agent source path
}
When I've run with a server listening I got the following output:
CArtAgO Http Server running on http://127.0.1.1:3273
Jason Http Server running on http://127.0.1.1:3272
Looking for rmi://10.0.0.11/cartago_node
java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is:
java.net.ConnectException: Connection refused
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:130)
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
at java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
at com.sun.proxy.$Proxy6.join(Unknown Source)
at cartago.infrastructure.rmi.CartagoInfrastructureLayer.joinRemoteWorkspace(CartagoInfrastructureLayer.java:62)
at cartago.CartagoService.joinRemoteWorkspace(CartagoService.java:372)
at cartago.NodeArtifact.joinRemoteWorkspace(NodeArtifact.java:99)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at cartago.ArtifactOpMethod.exec(ArtifactOpMethod.java:39)
at cartago.Artifact.doOperation(Artifact.java:407)
at cartago.Artifact.access$200(Artifact.java:32)
at cartago.Artifact$ArtifactAdapter.doOperation(Artifact.java:1275)
at cartago.WorkspaceKernel.serveOperation(WorkspaceKernel.java:1136)
at cartago.WorkspaceKernel.access$000(WorkspaceKernel.java:48)
at cartago.WorkspaceKernel$EnvironmentController.run(WorkspaceKernel.java:1477)
When I've run without a server listening the output was:
CArtAgO Http Server running on http://127.0.1.1:3273
Jason Http Server running on http://127.0.1.1:3272
java.rmi.ConnectException: Connection refused to host: 10.0.0.11; nested exception is:
java.net.ConnectException: Connection refused
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:619)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:216)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:202)
at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:342)
at sun.rmi.registry.RegistryImpl_Stub.lookup(Unknown Source)
at java.rmi.Naming.lookup(Naming.java:101)
at cartago.infrastructure.rmi.CartagoInfrastructureLayer.joinRemoteWorkspace(CartagoInfrastructureLayer.java:58)
at cartago.CartagoService.joinRemoteWorkspace(CartagoService.java:372)
at cartago.NodeArtifact.joinRemoteWorkspace(NodeArtifact.java:99)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at cartago.ArtifactOpMethod.exec(ArtifactOpMethod.java:39)
at cartago.Artifact.doOperation(Artifact.java:407)
at cartago.Artifact.access$200(Artifact.java:32)
at cartago.Artifact$ArtifactAdapter.doOperation(Artifact.java:1275)
at cartago.WorkspaceKernel.serveOperation(WorkspaceKernel.java:1136)
at cartago.WorkspaceKernel.access$000(WorkspaceKernel.java:48)
at cartago.WorkspaceKernel$EnvironmentController.run(WorkspaceKernel.java:1477)
So, it shows that the client found the server but something wrong happened and the connection was refused. What is happening? Which is the default CArtAgO's connection port?
CArtAgO uses Java RMI, the default port is 20100. For LipeRMI connection the default port is 20101. Other constants can be checked in http://www.emse.fr/~boissier/enseignement/maop17-spring/doc/api/cartago-api/index.html?constant-values.html
It is suggested to leave server and client with no restrictions checking whether iptables INPUT, FORWARD and OUTPUT are showing ACCEPT for any case. You can use the following command:
$ iptables -L -v
On linux with JaCaMo application running you can see if the port 20100 was opened by the app (you can use ss or netstat). The response should be "LISTEN" for 20100 port
$ ss -tnl | grep 20100
or
$ netstat -tuplen | grep 20100
It is also necessary to have DNS working for the machines because the connection will use names. You may test it by command ping using machine names. From clients:
$ ping name_server
From server (ping clients)
$ ping name_client1
In case of no DNS server to solve names, it is necessary to edit /etc/hosts file. Considering the server named 'myserver_hostname' on ip 192.168.0.1 and client named 'myclient_hostname' on ip 192.168.0.2, the file on both machines, server and client, may be like this:
127.0.0.1 localhost
#127.0.1.1 myserver_hostname -- RMI will not use it anymore
192.168.0.1 myserver_hostname
192.168.0.2 myclient_hostname

Enabling non root user to run tomcat with port 443

I am trying to run tomcat with https as a non-root user. Configured server.xml with required port modification and added SSL configuration.
However when I execute sudo systemctl restart tomcat get following error in catalina.out
org.apache.coyote.AbstractProtocol.init Failed to initialize end point associated with ProtocolHandler ["https-jsse-nio-443"]
java.net.SocketException: Permission denied
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
Follow this post
Resolution point number 5 works better
# setcap cap_net_bind_service+ep /path/to/bin/java

Play2 IntelliJ leads to akka.stream.BindFailedException$: bind failed on Linux

When I try to run my (local) play application via the play2 plugin from intellij I get:
[ERROR] [06/03/2017 23:21:10.985] [play-dev-mode-akka.actor.default-dispatcher-2] [akka://play-dev-mode/system/IO-TCP/selectors/$a/0] Bind failed for TCP channel on endpoint [/0.0.0.0:80]
java.net.SocketException: Permission denied
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at akka.io.TcpListener.liftedTree1$1(TcpListener.scala:56)
at akka.io.TcpListener.<init>(TcpListener.scala:53)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at akka.util.Reflect$.instantiate(Reflect.scala:65)
at akka.actor.ArgsReflectConstructor.produce(IndirectActorProducer.scala:96)
at akka.actor.Props.newActor(Props.scala:213)
at akka.actor.ActorCell.newActor(ActorCell.scala:555)
at akka.actor.ActorCell.create(ActorCell.scala:581)
at akka.actor.ActorCell.invokeAll$1(ActorCell.scala:454)
at akka.actor.ActorCell.systemInvoke(ActorCell.scala:476)
at akka.dispatch.Mailbox.processAllSystemMessages(Mailbox.scala:282)
at akka.dispatch.Mailbox.run(Mailbox.scala:223)
at akka.dispatch.Mailbox.exec(Mailbox.scala:234)
at akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
at akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
at akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
akka.stream.BindFailedException$: bind failed
If however, I run it via sbt run, everything works like a charm.
1) Why is that?
2) How can I fix this? (Running on Linux 4.11 here - I understand that the port is only allowed "sudoers", but then I wonder why the sbt-way works)
3) Any other way to run play in "debug mode"? I would like to set some break points and analyze the flow.
I ran into similiar issues before. Deploying to port requires permissions, if you want to strt the service on local, you can change the port to 9000, if you don'5 want this issue to occur. Then, when you deploy on production, you can change it to 80 and follow this guide :
https://www.playframework.com/documentation/2.5.x/Deploying
If you have changed build.sbt to listen on port 80, remove that line. IntelliJ still thinks app wants to run on 80
And also:
If you have changed application.conf, make sure port is not set to 80.

Resources