# sudo



## pavlar (Mar 17, 2020)

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?


----------



## SKull (Mar 17, 2020)

Is your sudoers file corrupted? I'd rewrite it to make sure.


----------



## pavlar (Mar 17, 2020)

How to check it?


----------



## SirDice (Mar 17, 2020)

If the sudoers file is corrupt sudo(8) will stop working completely. It's quite finicky about errors. 



pavlar said:


> 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.


----------



## pavlar (Mar 17, 2020)

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* )


----------



## Alain De Vos (Mar 17, 2020)

Not an answer but do you need sudo ? I only use su.


----------



## SirDice (Mar 17, 2020)

pavlar said:


> 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.



pavlar said:


> 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?


----------



## SKull (Mar 17, 2020)

> Don't rule out bad cables.



Rather, rule that one out first


----------



## pavlar (Mar 17, 2020)

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.


----------



## pavlar (Mar 17, 2020)

Alain De Vos said:


> Not an answer but do you need sudo ? I only use su.


Because I log on ssh as a user and use this password for sudo. Less unnecessary movements


----------



## SirDice (Mar 17, 2020)

pavlar said:


> 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.


----------



## aragats (Mar 17, 2020)

SirDice said:


> 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.


----------



## pavlar (Mar 18, 2020)

aragats said:


> I'd add another possible cause I experienced in the past: check your MTU settings, pavlar . SSH doesn't like fragmented packets.




```
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
```


----------



## pavlar (Mar 18, 2020)

SirDice said:


> 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


----------



## aragats (Mar 18, 2020)

pavlar said:


> igb0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500


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).


----------



## SirDice (Mar 18, 2020)

pavlar said:


> 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.


----------



## pavlar (Mar 19, 2020)

SirDice said:


> 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


----------



## pavlar (Mar 19, 2020)

aragats said:


> 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


----------



## rootbert (Mar 19, 2020)

maybe DNS causes the delay ... is your hostname in /etc/hosts?


----------



## ralphbsz (Mar 20, 2020)

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.


----------

