sudo

Sometimes when entering a valid password sudo of valid user by ssh there is a big delay and ping disappears to the server. Resume is obtained only by rebooting. What could happen? Maybe its firewall?
 
If the sudoers file is corrupt sudo(8) will stop working completely. It's quite finicky about errors.

Sometimes when entering a valid password sudo of valid user by ssh there is a big delay and ping disappears to the server.
Unless you configured sudo(8) to use LDAP, sudo(8) has nothing to do with the network, it doesn't use the network and it doesn't influence the network. So I suspect there are different issues at play here. It's possible the network connection is just bad, which would result in bursts and stalls of anything you type and everything being printed by the remote end.
 
I tried to ping from two computers from different subnets. And the distance between the computers and the server is equal to the length of UTP cable (approximately 6 meters)end switches. This is unlikely to be a network problem. Rather, it may be a problem with the network card of the server, but I changed it and the situation has not changed. I installed system and sudo from the packages (pkg install sudo )
 
And the distance between the computers and the server is equal to the length of UTP cable (approximately 6 meters)end switches. This is unlikely to be a network problem. Rather, it may be a problem with the network card of the server, but I changed it and the situation has not changed.
Don't rule out bad cables.

I installed system and sudo from the packages (pkg install sudo )
The problems with sudo(8) are probably a red herring. What happens when you run it on the local console?
 
I do not start locally because many servers of U1 are in the rack and it’s difficult to connect the monitor there- only during an accident. It is unlikely that 2 different cables from computers on different subnets have the same interference.
 
I do not start locally because many servers of U1 are in the rack and it’s difficult to connect the monitor there- only during an accident.
To rule out any issues with sudo(8) itself you should test it on the local console. If you don't get the delays there then you know it's not sudo(8) that's causing the delays.
 
I suspect there are different issues at play here. It's possible the network connection is just bad, which would result in bursts and stalls of anything you type and everything being printed by the remote end.
I'd add another possible cause I experienced in the past: check your MTU settings, pavlar . SSH doesn't like fragmented packets.
 
I'd add another possible cause I experienced in the past: check your MTU settings, pavlar . SSH doesn't like fragmented packets.
Code:
ifconfig| grep -i MTU
igb0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
igb1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
igb2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
igb3: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
 
To rule out any issues with sudo(8) itself you should test it on the local console. If you don't get the delays there then you know it's not sudo(8) that's causing the delays.
This rack.But server monitor connectors are on the back.Supermicro server manufacturers probably didn't think it through
 

Attachments

  • 1807755268_w640_h640_1807755268 (1).png
    1807755268_w640_h640_1807755268 (1).png
    41.1 KB · Views: 86
This rack. But server monitor connectors are on the back. Supermicro server manufacturers probably didn't think it through
I know what a 19" rack looks like. I was practically living in a datacenter when I worked for various hosting companies. All datacenters I've ever been in (quite a lot over the past 15 or so years) had trolleys or carts with a monitor and keyboard attached specifically for this.
 
I know what a 19" rack looks like. I was practically living in a datacenter when I worked for various hosting companies. All datacenters I've ever been in (quite a lot over the past 15 or so years) had trolleys or carts with a monitor and keyboard attached specifically for this.
In the rack there is a 16-port KVM Switch but only for keyboards and mouse PS/2 (all servers except for this have such connectors), and only this server mouses and keyboards USB
 
Obviously by default it's 1500. In case when you have e.g. PPPoE DSL in between 2 nodes, the optimal MTU should be 1492 (maybe even 1452).
We use only UTP and fiber optic cable for LAN and only optic cable to Internet-provider
 
No local console? That's sad. My next suggestion was going to be: whatever happens right after sudo might be causing the machine to "crash". And then I say "crash", I don't necessarily mean a kernel crash with stack traces on the console (although that's a very real possibility), but all manner of other crazy problems. How to debug them? Well, not over the network, since the network is down at that time. So it will be debugged over the console. I fear that you will have to find a monitor and keyboard and connect them, even if your situation is unusually difficult.

If you think I'm being mean and picking on you ... I have exactly the same problem. We have a small pump station at home, which has several pumps, quite a bit of control system gear (pressure measuring, electric motor inverters, emergency generator switchover), and in the electrical control cabinet there is a small Raspberry Pi I added. Recently, I upgraded the OS on the pi (it is not FreeBSD), and since then it has developed a very nasty habit: About 50% of the time, after booting, the network on it won't work. I have no idea why not, there are no error messages in the system logs. The only way I have to fix it is to reboot it. Obviously, I can't log in remotely to it, duh, no network. It has no console (more about that below). No reboot button. So I just have to cut power to it, without a clean shutdown. Yes I know how dangerous that is to file systems, but there are currently no other options. To debug it, I will need a console.

And this is where it gets ugly. Because the control cabinet is quite densely packed, and the Pi is installed in a DIN rail case, there is no way to get a HDMI cable attached to it. I do have a small monitor that can use the DSI ribbon cable, but I don't have a ribbon cable that's long enough to actually reach in there. I have a USB "DisplayLink" monitor, but a Pi won't use a USB monitor as a normal console. Because of the Coronavirus "shelter in place" order and store closures, I can't just go to an electronics store and buy a longer ribbon cable or an angled HDMI connector or something like that. So for the next few days, I'll just have to pray that the problem won't get worse, and in the meantime wait for my longer ribbon cable to show up. And if the regular hard crash and reboot damages my file system, I just get to spend half hour taking it apart, taking the SD card out, and reflashing it. In retrospect it is clear that not designing a console connection into the setup was really dumb. The problem with learning from one's own mistakes is that you have to make them first.
 
Back
Top