I am currently creating a website on Codeanywhere that communicates with a back-end API/server. I ran my server.js node script with my ports on 8080 (front-end) and 8081 (server). However, I normally close the connection with Ctrl + C but I accidentally used Ctrl + Z to close the server down and since then I cannot run it again. Since I accidentally used Ctrl + Z and closed the tab on codeanywhere before doing anything else out of fear of damage my local host on codeanywhere when I run the script will not connect but instead take too long and time out. I am desperate for a solution as this is for a university module.
Pressing Ctrl+z does not stop your application, it sends it to the background. I wouldn't describe it as being in a running state but resources (such as the port) it was previously using remains bound to it.
Your application was timing out because you were trying to start another instance that shared the same resource (port) as the paused one.
To fix, type fg in your terminal and it should restore your application.
I know this question was asked a long time ago but who knows who this answer might help.
You need to kill the node process. By doing Ctrl Z you are just suspending it, without freeing it's locked resources (like the TCP port your are listening to).
If no other Node.js processes are running and killall is available you could easily do killall node and then restart the server. Else use any tool to kill the node process.
Related
I know that this question look similar to VSCode [Remote Development] [Forward Port] work? but it isn't.
When I launch a command which starts a web server on a random port (and prints out the url to access it),
VS Code auto detects the newly allocated port and starts port forwarding that port to my host machine.
How does this happen? Does VS Code check for newly allocated port by the current command ? If so, how does the shell script for this look like ?
This has been answered by VSCode developer on github here.
To summarize, VSCode will actively look into the proc file system ie. /proc directory and detect the port that was allocated and then start auto portforwarding it.
Assuming remote.autoForwardPorts is set to true, it depends on the operating system that VS Code is running on.
On Windows and Mac remotes, it picks up from the terminal output (the output option under remote.autoForwardPortsSource):
Note: on Windows and Mac remotes, selecting the process option has no effect and output will be used.
On other operating system remotes, if the process option is selected, VS Code watches for processes that start with a port included, and automatically forwards ports for those:
Suppose we have two process having the same port, but one at a time one will be using it and other one will be in passive mode and once the active process goes down, the passive will start reading from the port.
now since in linux everything is a file descriptor, i wanted to know is there any way where passive process can immediately start reading from the port.
Currently i am closing the port in active process and then again open it in the passive once it becomes active.
Thanks in advance.
No, only one process can read from a port at a time. Even on linux, when a process uses the port, it locks it. It is linux architecture that everything is a file(with exception of network devices). But these device files(or ports) are special files or device files. You cannot manipulate them as normal files.
recently I encounter a problem. I am using two programs A and B, developed by someone else, which use TCP sockets to communicate each other, A is server, B is client. That is what I observed: when I start both A and B, they run and communicate with each other, if I first kill A, then restart A again, now by checking the processes, A is successfully launched, but cannot be connected by B, no matter I restart B. however, If I continue to kill this non-detectable A and start A again, it can be detected by B.
At the same time, if I close B's socket before kill A, then when I start A and B, they work very well.
what the problem might be and is there some way to see the opened sockets when I kill A?
It depends on the OS you are using.
lsof -p <pid> is quite common on UNIX and lets you list all file descriptors used by a process.
netstat is probably available and will also list opened ports.
This is probably due to the TIME_WAIT state. When you kill A, the server port is still allocated by the OS and can be reused only if A sets a specific flag when opening server port to be able to reuse this port (SO_REUSEADDR). Otherwise, A won't be able to reuse the server port until it is closed by the OS (can take a few minutes, reason why when you continue to kill A, at some point, the port is available again). I don't know what A is doing if it cannot open the server port because of that.
I'm trying to re-launch a WCF service that I killed earlier, but I'm getting an AddressAlreadyInUseException. The port it's attempting to use is 1819.
I ran netstat -nao from the command line, and have found there is a listening process on port 1819, that has a PID of 4840. I went into Process Explorer (from SysInternals) to try to kill PID 4840, but it's not there.
I'm guessing PID 4840 was the WCF service running earlier (that I killed) but it didn't clear out the connections. How can I force a refresh of these ports being listened in on? Otherwise I'll have to reboot every time this happens.
It doesn't look like there's a way to refresh it. For now I have reconfigured the service to use another port until it's more convenient for me to restart.
I had same problem, the only way to make my port free and refreshed is just by restarting the computer. It is a bit tedious but that was the only way for me to solve the problem
I am writing a script that powers on a system via network. And then i need to run a few commands on the other host. How do I know whether the system has powered on?
My programming language is Perl and the target host is RHEL5.
Is there any kernel interrupt or network boot information that indicates the system has powered on and the os has loaded?
[In a different scenario] I was also wondering just in case if i just switch on my Machine manually. when is it exactly said to have powered on. and when is the OS is supposed to have booted completely for a network related operation such as executing a network command there. What if the system is on DHCP how would a remote system then search for this machine [i guess it is possible via mac address. but if i am wrong ].
If I have missed out any info please feel free to ask me. If you have any suggestions to make the task easier please surface them :)
thanx
imkin
Well, I'd say the system is booted when it can perform the request you've made of it. That is, the sshd daemon is running. That's booted sufficiently for your purposes (I assume - substitute for whatever daemon you really need).
So, I'd send the power-on signal, and check back every 15-30 seconds to see if I could connect. If I've failed to connect within whatever is a reasonable time for that machine (2 minutes or 5 minutes or whatever), then I'd send an alert to the IT support team. Well, I'd send it to myself first, and only once I've investigated a few failures or so and found them to all be legitimate would I start sending it directly to IT.
DHCP is kind of a different question. You'd have to start learning about broadcasting, or having a daemon on that machine "call home" during boot to register its current IP address. And it would have to "call home" every time a DHCP renewal changed its IP address. This is decidedly more convoluted. Try to avoid DHCP on such server machines if at all possible.
On the rebooting machine you can install a script in your crontab with the special #reboot assertion (see man 5 crontab). That script could send a notification of some kind to the other machine, notifying it that it's up now.
I think checking for sshd sounds like a good approach.
As for the DHCP problem: if the other computer is on the same subnet you can look it up by MAC address using Net::ARP.
How about adding a script to the remote machine which gets run on startup to have it tell you when it is ready.