Hacker News new | past | comments | ask | show | jobs | submit login

Interesting read.

But i bumped into the same problem recently while working on distributed simulation. I was writing an agent for an application which talks to clients over ssh. I started getting the same error when i cranked up machine count to 60.

I googled like every layman and zeroed in on MaxStartups. Looked at the manual to cross verify and fixed the issue in 5 minutes. I agree with what ever he did after he found out the issue but it was a clear case of SSH throwing an error. Why not just look up manual or google instead of wasting time on laborious packet inspection.




Because at their scale, people actually need to understand the issue rather than just applying fixes blindly plucked from the Internet. Don't get me wrong, Google is my go-to as well, but I suspect that they need to dig a little deeper.


Fair enough.

But wouldn't doing investigation on the error provide data point to help debug the issue. They are trying to fix a customer issue and time is also of importance here.

> just applying fixes blindly plucked from the Internet.

I wasn't recommending that.


> Why not just look up manual or google instead of wasting time on laborious packet inspection.

When you've got a load balancing layer, and virtual machines, and interacting with the real world, there's a reasonable chance that the problem is not a (relatively) simple application configuration issue. If you've looked through enough of these, getting a pcap (especially with an identified customer) and looking through it with Wireshark is relatively quick.


I could have worded it better like "why packet inspection to start with".


I love packet inspection, but I always feel that if I have to go to that depth, then we missed an opportunity to have observability (metrics/logging) earlier.


Because pcap lies a lot less than everything else.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: