in Solaris 10, when server restart, the backup daemon (tina_daemon) does not work properly when calling for another executable to shutdown the application services.
however, when manually restart the backup daemon, the calling for the executable works fine.
I found the following lines in the log-file:
8|9|tina_daemon|780|1|3|1373964994|1373964994|10739|tina_daemon_1|<host name deleted>|~|root|~|backup_poc_tina|backup-poc|Event handler daemon started|0|~|~|~|~|~|~|
8|9|tina_daemon|880|256|3|1373964994|1373964994|10739|tina_daemon_1|<host name deleted>|~|root|~|backup_poc_tina|backup-poc|Service opened, host "<host name deleted>", Time Navigator Enterprise Edition Version 4.2.8.8 P4680|0|~|~|~|~|~|~|
8|14|TNUnixSocketImpl::initNetServiceTcp|11|1|1|1373965001|1373965001|10963|tina_daemon_1|<host name deleted>|~|root|~|backup_poc_tina|backup-poc|Unable to bind 5 socket, retos=125 "Address already in use"|0|~|~|~|~|~|~|
8|14|vos_init_net_service_tcp|1|1|4|1373965001|1373965001|10963|tina_daemon_1|<host name deleted>|~|root|~|backup_poc_tina|backup-poc|Unable to initialize network service of TCP type, retex=TN_ERR_CONFLICT_RESS (conflict in access to the same resource)|0|~|~|~|~|~|~|
is it a potential that not enough share memory? since the tina_daemon use 2 ports which already define in the /etc/services
I feel very weird since when manually using root to restart the tina_daemon, everything works fine. When server restart with the startup script (which i changed to similar to manul restart), it does not work well for calling another executable to shutdown the application. It shutdown the application half way, and cause the application hang (and ultimate need to restart the application)
Related
I've been using Mongo for a while now, and I never had any kind of errors. But today, I tried running the mongo command in my terminal and I got the following error:
Error connecting to 127.0.0.1:27017 :: caused by :: No connection could be made because the target machine actively refused it. :
I have my PATH variable for Mongo properly configured in my environment variables as follows:
C:\Program Files\MongoDB\Server\4.4\bin
so I doubt that is the issue. I remember going through my task manager yesterday and I accidentally terminated a program running in the background related to Mongo, but I can't seem to remember exactly what it was called, and I really think that that's the root of my problem, because before having terminated that Mongo program in my task manager I had never ran across this connection problem before.
By terminating a program in the background, I'm going to assume you didn't just end process, otherwise a simple computer restart would fix your issue. And in some cases, that same program would've relaunched when you launched MongoDB. But if you disabled a service and need to find which service needs to be running to be able to connect to your MongDB then I would suggest going through your Windows Services list and seeing which ones you disabled and looking one relating to TCP or SNMP.
This is because MongoDB Wire Protocol is a simple socket-based, request-response style protocol. You communicate with the database server through a regular TCP/IP socket and since you can't remember which one you "terminated" and any number of services related to networking can cause a dependency to be absent, I can't be more specific in helping you determine which one you need to turn back on and you'll have to do it through trial and error but I can at least offer you some guidance, hopefully.
Specifically you can either
Run system configuration using
msconfig
In a run box, navigating to the Services tab, order the list by Date Disabled to find the service that was disabled which correlates with when you when snooping through task manager, or
Run Task manager and navigate to the Services Tab, then Open Services, and order them by Status or by Name, and look for any service that includes TCP/IP, COM+, Port direction, etc. to see which one is disabled and change the configuration from anything but Disabled and then stat it manually and run MongDB again.
It's about as specific as I can get without knowing anything more than you terminated some program running in the background but I hope it helps.
The background process (daemon) for MongoDB is called 'mongod'. It's an executable in your bin directory inside your mongodb installation. You can just execute it in the terminal.
Run:
C:\Program Files\MongoDB\Server\4.4\bin\mongod.exe
I have setup the apache cloudstack on CentOS 6.8 machine following quick installation guide. The management server and KVM are setup on the same machine. The management server is running without problems. I was able to add zone, pod, cluster, primary and secondary storage from the web interface. But when I tried to add an instance it is not showing any templates in the second stage as you can see in the screenshot
However, I am able to see two templates under Templates link in web UI.
But when I select the template and navigate to Zone tab, I see Timeout waiting for response from storage host and Ready field shows no.
When I check the management server logs, it seems there is an error when cloudstack tries to mount secondary storage for use. The below segment from cloudstack-management.log file describes this error.
2017-03-09 23:26:43,207 DEBUG [c.c.a.t.Request] (AgentManager-Handler-
14:null) (logid:) Seq 2-7686800138991304712: Processing: { Ans: , MgmtId:
279278805450918, via: 2, Ver: v1, Flags: 10, [{"com.cloud.agent.api.Answer":
{"result":false,"details":"com.cloud.utils.exception.CloudRuntimeException:
GetRootDir for nfs://172.16.10.2/export/secondary failed due to
com.cloud.utils.exception.CloudRuntimeException: Unable to mount
172.16.10.2:/export/secondary at /mnt/SecStorage/6e26529d-c659-3053-8acb-
817a77b6cfc6 due to mount.nfs: Connection timed out\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getRootDir(Nf
sSecondaryStorageResource.java:2080)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSe
condaryStorageResource.java:1829)\n\tat
org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeReques
t(NfsSecondaryStorageResource.java:265)\n\tat
com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat
com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:833)\n\tat
com.cloud.utils.nio.Task.call(Task.java:83)\n\tat
com.cloud.utils.nio.Task.call(Task.java:29)\n\tat
java.util.concurrent.FutureTask.run(FutureTask.java:262)\n\tat
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)\
n\tat
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\
n\tat java.lang.Thread.run(Thread.java:745)\n","wait":0}}] }
Can anyone please guide me how to resolve this issue? I have been trying to figure it out for some hours now and don't know how to proceed further.
Edit 1: Please note that my LAN address was 10.103.72.50 which I assume is not /24 address. I tried to give CentOs a static IP by making the following settings in ifcg-eth0 file
DEVICE=eth0
HWADDR=52:54:00:B9:A6:C0
NM_CONTROLLED=no
ONBOOT=yes
BOOTPROTO=none
IPADDR=172.16.10.2
NETMASK=255.255.255.0
GATEWAY=172.16.10.1
DNS1=8.8.8.8
DNS2=8.8.4.4
But doing this would stop my internet. As a workaround, I reverted these changes and installed all the packages first. Then I changed the IP to static by the same configuration settings as above and ran the cloudstack management. Everything worked fine untill I bumped into this template thing. Please help me figure out what might have went wrong
I know I'm late, but for people trying out in the future, here it goes:
I hope you have successfully added a host as mentioned in Quick Install Guide before you changed your IP to static as it autoconfigures VLANs for different traffic and creates two bridges - generally with names 'cloud' or 'cloudbr'. Cloudstack uses the Secondary Storage System VM for doing all the storage-related operations in each Zone and Cluster. What seems to be the problem is that secondary storage system vm (SSVM) is not able to communicate with the management server at port 8250. If not, try manually mounting the NFS server's mount points in the SSVM shell. You can ssh into the SSVM using the below command:
ssh -i /var/cloudstack/management/.ssh/id_rsa -p 3922 root#<Private or Link local Ip address of SSVM>
I suggest you run the /usr/local/cloud/systemvm/ssvm-check.sh after doing ssh into the secondary storage system VM (assuming it is running) and has it's private, public and link local IP address. If that doesn't help you much, take a look at the secondary storage troubleshooting docs at Cloudstack.
I would further recommend, if anyone in future runs into similar issues, check if the SSVM is running and is in "Up" state in the System VMs section of Infrastructure tab and that you are able to open up a console session of it from the browser. If that is working go on to run the ssvm-check.sh script mentioned above which systematically checks each and every point of operation that SSVM executes. Even if console session cannot be opened up, you can still ssh using the link local IP address of SSVM which can be accessed by opening up details of SSVM and than execute the script. If it says, it cannot communicate with Management Server at port 8250, I recommend you check the iptables rules of management server and make sure all traffic is allowed at port 8250. A custom command to check the same is nc -v <mngmnt-server-ip> 8250. You can do a simple search and learn how to add port 8250 in your iptables rules if that is not opened. Next, you mentioned you used CentOS 6.8, so it probably uses older versions of nfs, so execute exportfs -a in your NFS server to make sure all the NFS shares are properly exported and there are no errors. I would recommend that you wait for the downloading status of CentOS 5.5 no GUI kvm template to be complete and its Ready status shown as 'Yes' before you start importing your own templates and ISOs to execute on VMs. Finally, if your ssvm-check.sh script shows everything is good and the download still does not start, you can run the command: service cloud restart and actually check if the service has gotten a PID using service cloud status as the older versions of system vm templates sometimes need us to manually start the cloud service using service cloud start even after the restart command. Restarting the cloud service in SSVM triggers the restart of downloading of all remaining templates and ISOs. Side note: the system VMs uses a Debian kernel if you want to do some more troubleshooting. Hope this helps.
Suddenly Websphere server is automatically started.
I stop many times but started again automatically.
Even I removed project from the web sphere and removed websphere from the project and Again add for the same.. But still I it is starting.
I also run the below command,
Server stop server_name
below Message is showing
Stopping server server_name
So it is not stoping. How to stop forcefully? or Kill existing process?
Your question doesn't state what OS you're running on, but Liberty doesn't currently ship with any means to automatically start the server (like a Windows service), so when you say "started again automatically", it is more likely that the server is never shutdown. Liberty runs as a process that can be killed and the process id can be determined by looking at the messages.log file in the server logs directory. The preamble of the file will contain a line like this:
process = 11488#YourHostName
Depending on the OS you're running on, you can use the kill command (Linux or MacOS), or the Windows Task manager to end the process. When you restart the server, you may want to specify the --clean option like this:
server start defaultServer --clean
This is what I get:
Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: 8099; nested exception is: java.net.BindException: Address already in use: JVM_Bind.
I have to mention that I use liferay 7.0 ga3 and tomcat 8.0.32, my ide is eclipse luna.
I tried to run in command line start rmiregistry some_port, but it didn't do nothing, just popped up a window and did effectively nothing.
Thank you!
Tomcat uses port 8099 for JMX communication (which is crucial for debugging). There is already another process using this port. Here are some possibilities:
In general, it is more practical just to finish the other process. A LOT OF TIMES, the other process is Spotify. Are you using Spotify? If so, just finish it, start Liferay and then reopen Spotify. Annoying but straightforward.
You started another Tomcat bundle. In this case, you only have to shut it down.
A previous Liferay execution just crashed and let a rogue Java process listening on the port. In this case, go to the terminal and execute jps:
$ jps
28058 org.eclipse.equinox.launcher_1.3.200.v20160318-1642.jar
1787 Bootstrap
14207 Jps
Kill the process that is labeled Bootstrap:
$ kill -9 1787
Technically, you could change the port on Tomcat. Open the server configuration, click on "Open Launch Configuration." Then, go to the "Arguments" tab and look for 8099. Basically, follow the GIF below:
However, I do not know all the consequences of it. I used to do it with Tomcat servers without LDS, not sure what problems it could bring with LDS.
Please check whether the shutdown port mentioned in the server.xml file under liferay-dxp-(version)-ga1\tomcat-(version)\conf folder.
Use the below command to find the ports running in your windows machine:
netstat /nao | findstr "80"
then change the shutdown port to any available ports, say 8010:
<Server port="8010" shutdown="SHUTDOWN">
restart the server.
Please try this step if the shutdown port is already in use.
I'm looking at hosting a number of small, static websites and have been looking at a few alternatives including G-WAN. At the moment I'm just trying to get a feel for how well each server suits my needs before picking one.
G-WAN seems to do exactly what I want, though I'm running into problems with updating the configuration (by adding new folders) after the server's started. I can't find anything in the documentation or online about this, so I don't know if I'm doing anything dumb, running an unsupported configuration, or whether it's a feature that doesn't exist in G-WAN.
Here's my setup:
G-WAN 3.3.28 64-bit on Ubuntu 12.04.1 LTS.
I have what I think is the required minimal folder structure:
0.0.0.0_80
#0.0.0.0
www
$site.com
www
$othersite.com
www
I startup gwan via (I'm still messing around, so hopefully ):
sudo .\gwan -d
Everything works brilliantly. I add $thirdsite.com/, $thirdsite.com/www/, and $thirdsite.com/www/index.html; then when I try to visit thirdsite.com it gives me the root host (ie it doesn't seem to pick up the changes).
To reload the modified configuration, I have to either do:
sudo .\gwan -k; sudo .\gwan -d
or kill the non-angel process (kill -s 15) to restart the child process.
Can G-WAN reload the host definitions another way? If so, is it something that works out of the box or is there a command that can cycle the server without dropping requests made to other hosts (/is it safe to kill -s 15 on the non-angel process + if so, is there a reliable way to identify the process)? Thanks in advance!
G-WAN loads the host definitions at startup and does not check them as time goes to reload them dynamically.
To force a reload, you have to stop the child process (when in daemon mode) and v3.9+ keeps the old child alive the time to process any pending request while the new child accepts new connections.
Since stopping the child can also be done from the maintenance script or from a handler or from a servlet by just running exit(0) there is not need for a dedicated command.
Note that when you use kill you can pick the pid file from the gwan directory:
the parent process starts with a capital letter: Gwan_xxxx.pid
the child process starts with a lowercase letter: gwan_xxxx.pid
That will make your life easier.