3 ms·

> Why? Because you can't have two processes using the same port, and the process that was using the port is now not responding. Perhaps you don't even want to

> Why? Because you can't have two processes using the same port, and the process that was using the port is now not responding. Perhaps you don't even want to go through the process of learning what PID it has, you just want the port back so you can relaunch the dev server on localhost. your criticisms of this program do not seem well-founded because your assuming that it will be used improperly. In many cases this is a very simple problem with a simple solution

hayst4ck 3y ago
> the process that was using the port is now not responding. Yes, but why? Between strace, ps, atop, lsof, logging, and understanding the OS and TCP, it shouldn't be horrific to figure out what is happening. The very same skills to understand the problem are valuable to a lot of problems and investing in one simple problem is a further investment in future problems. "I don't have the telemetry to understand this" is, if nothing else, a deferred problem. Having devs that aren't prepared for oncall is also a problem. "Why is my process hung?" is something I hope most devs can solve. Not solving a frequently hanging process is short-termism. Not solving problems creates a learned helplessness about systemic problems. They build up and get addressed too late. > Because you can't have two processes using the same port https://lwn.net/Articles/542629/ https://lwn.net/Articles/542629/ Maybe this is relevant: https://hea-www.harvard.edu/~fine/Tech/addrinuse.html https://hea-www.harvard.edu/~fine/Tech/addrinuse.html > criticisms of this program I am a little harsh because it increases complexity when no increased complexity is needed. That is my only strong criticism, a whole new program is invoked when we have plenty of very sufficient (composable) tools already.