Почему `su` выдает "su: Ошибка аутентификации" даже при запуске от имени пользователя root?

В качестве частичного ответа на мой собственный вопрос я добился значительных улучшений надежности за счет следующего:

Изменение подключаемого модуля ядра управления tcp _перегрузкой _с кубического по умолчанию на bbr значительно устранило раздувание буфера, которое наряду с радиосоединением с потерями лежит в основе проблемы.

Это потребовало загрузки модуля ядра tcp _bbr, а также изменения модели организации очередей net.core на справедливую организацию очередей, чтобы обеспечить синхронизацию модуля bbr.

Для RPI значения по умолчанию::

net.ipv4.tcp _перегрузка _control=cubic

net.core.default _qdisc=pfifo _быстрый

Команды для изменения этого во время работы -::

modprobe tcp_bbr
sysctl -w net.core.default_qdisc=fq
sysctl -w net.ipv4.tcp_congestion_control=bbr

Сейчас я запускаю их из сценария, вызываемого из /etc/rc.local. Их можно легко сделать постоянными, изменив modprode.d и sysctl.conf или в виде файла в sysctl.d.

Результатом является гораздо более плавный ответ по ssh и гораздо более надежная массовая передача, которая, несмотря на задержку, быстро восстанавливается и надежно завершается, немедленно возвращаясь в командную строку (, а не приостанавливаясь на 100% в течение длительных периодов времени. -например, 1 -за 3 минуты до возвращения, как в случае кубического управления перегрузкой ).

Компромиссом -является общая скорость, однако надежность важнее.Например, передача файла размером 283 КБ по радиоканалу с использованием scp теперь приводит к:

100%  283KB   2.5KB/s   01:51

Это компромисс, которым я пока вполне доволен. Тем не менее, длительные процессы массовой передачи по-прежнему проблематичны и в конечном итоге останавливаются и никогда не завершаются.

Например, apt -get update работает более часа (зависает на файле размером 11,7 МБ ), требует периодического возврата каретки через ssh-терминал для продолжения работы и в конечном итоге зависает до очень длительная задержка, хотя и не все вместе.

В следующем скрин-скрине процесс длился более 1 часа, с несколькими CR каждые 10 -15 минут и задержкой примерно в 5 минут между отправкой ^C и ответом терминала:

root@priotdev2:~# apt-get update
Get:1 http://mirror.internode.on.net/pub/raspbian/raspbian stretch InRelease [15.0 kB]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
Get:2 http://archive.raspberrypi.org/debian stretch InRelease [25.3 kB]                                                            
Get:2 http://archive.raspberrypi.org/debian stretch InRelease [25.3 kB]                                                            
Get:4 http://archive.raspberrypi.org/debian stretch/main armhf Packages [145 kB]                                                   
Get:5 http://archive.raspberrypi.org/debian stretch/ui armhf Packages [30.7 kB]                                                    
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
23% [3 Packages 270 kB/11.7 MB 2%]                                                                            2,864 B/s 1h 6min 15s
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
29% [3 Packages 1,263 kB/11.7 MB 11%]                                                                          131 B/s 22h 2min 19s
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
60% [3 Packages 5,883 kB/11.7 MB 50%]                                                                        16 B/s 4d 4h 13min 58s
60% [3 Packages 5,902 kB/11.7 MB 51%]                                                                         1,531 B/s 1h 2min 38s
66% [3 Packages 6,704 kB/11.7 MB 58%]                                                                                              

66% [3 Packages 6,704 kB/11.7 MB 58%]
Get:3 http://mirror.internode.on.net/pub/raspbian/raspbian stretch/main armhf Packages [11.7 MB]                                   
66% [3 Packages 6,735 kB/11.7 MB 58%]                                                                                              
66% [3 Packages 6,735 kB/11.7 MB 58%]
66% [3 Packages 6,745 kB/11.7 MB 58%]                                                                       32 B/s 1d 18h 37min 55s
66% [3 Packages 6,745 kB/11.7 MB 58%]                                                                       32 B/s 1d 18h 37min 55s
66% [3 Packages 6,745 kB/11.7 MB 58%]                                                                                              
66% [3 Packages 6,745 kB/11.7 MB 58%]
66% [3 Packages 6,746 kB/11.7 MB 58%]                                                                          230 B/s 5h 55min 46s

66% [3 Packages 6,747 kB/11.7 MB 58%]                                                                          148 B/s 9h 12min 47s^C
root@priotdev2:~# ^C
root@priotdev2:~# 
root@priotdev2:~# 

Прокрутив вправо приведенный выше дамп, можно увидеть ужасную пропускную способность (до 16 и 32 байт в секунду в некоторых случаях ).

Чтобы удалить конечные переменные с -по -, которые также включают спутниковый канал, процесс apt фактически использует восходящий RPI в качестве кэша apt (, который обновлен ), передачи представляют только трафик по радиоканалу.

Будем рады любым советам сообщества по дальнейшим улучшениям.