Долгий страт midnight commander в терминале Linux Mind

Догадался выполнить strace:

15:22:45.825552 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f793f3a7a10) = 2473 <0.000154>
15:22:45.825791 write(7, "precmd() { if [ ! \"${PWD##$HOME}"..., 238) = 238 <0.000066>
15:22:45.825934 rt_sigaction(SIGINT, {sa_handler=0x555aeacc9a50, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f793f8e13c0}, NULL, 8) = 0 <0.000052>
15:22:45.826074 select(10, [7 9], NULL, NULL, {tv_sec=10, tv_usec=0}) = 1 (in [7], left {tv_sec=9, tv_usec=999996}) <0.000071>
15:22:45.826244 read(7, "precmd() { if [ ! \"${PWD##$HOME}"..., 128) = 128 <0.000050>
15:22:45.826381 select(10, [7 9], NULL, NULL, {tv_sec=9, tv_usec=999996}) = 1 (in [7], left {tv_sec=9, tv_usec=999994}) <0.000038>
15:22:45.826498 read(7, "OME/}\"; fi; echo \"$USER@$(hostna"..., 128) = 113 <0.000038>
15:22:45.826608 select(10, [7 9], NULL, NULL, {tv_sec=9, tv_usec=999994}) = 1 (in [7], left {tv_sec=9, tv_usec=998503}) <0.001530>
15:22:45.828322 read(7, "/bin/sh: 2: Syntax error: Bad fd"..., 128) = 67 <0.000045>
15:22:45.828448 select(10, [7 9], NULL, NULL, {tv_sec=9, tv_usec=998503}) = 0 (Timeout) <10.004307>
15:22:55.832914 rt_sigaction(SIGINT, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f793f8e13c0}, NULL, 8) = 0 <0.000066>

тут вот поймался этот таймаут в 10 секунд

Запусти через стрейс, глянь что долго выполняется

srace -S mc

strace -S ms

В домашем и текущем каталоге очень много файлов?
Если в них много файлов то mc может начать тормозить.
Как решение используй команду cd в пустой или не очень большой каталог или запусти mc явно указав путь к каталогам:

mc path_to_dir1 parh_to_dir2

Нет, система практически пустая, ничего своего ещё не успел разместить.

Там вот в strace поймался таймаут, теперь не могу понять, что это значит. Что-то с hostname?

Опять проблема с hosts и DNS запросами?

Что-то с hostname?

В зависимости от настроек система пытается искать hostname через DNS.

Да вроде у меня имя хоста прописано в hosts на 127.0.0.1.

Я даже hostname себе поменял на IP адрес в локальной сети - один фиг, не помогает.

Какое содержимое /etc/hosts?

Судя по precmd() у вашего пользователя оболочка zsh.

Попробуйте запустить mc –nosubshell.

Да, так работает. Но если из mc попытаться отредактировать какой-то файл (mcedit) - опять timeout.

Выяснил ещё, что проблема наблюдается только у того пользователя, которого я сам создал через useradd. Видать, чего-то недосоздал.:(

Причём, опять же, если соединяться со сторонней системы к этой по ssh под именем этого пользователя - mc открывается быстро.

Эмм.

Ну так если «так работает» - может быть попытаться сменить shell на bash, или починить zsh? )

novamint-vmware

Ты в виртуалке запускаешь?

Покажи, что в /etc/hostname, покажи еще, что в /etc/resolv.conf.

127.0.0.1 localhost novamint-vmware novamint-vmware.domain novamint-vmware.localdomain

Попробуй не алиасы делать, а отдельные строчки для каждого хостнейма. Перезапустись.

По теме:

zsh медленный запуск mc

mc очень долго запускается.

И вот еще до кучи:

https://unix.stackexchange.com/questions/57439/slow-start-of-midnight-commander

https://midnight-commander.org/ticket/40

https://midnight-commander.org/ticket/3082

https://midnight-commander.org/ticket/1

Да, в виртуалке. В hosts изначально было разными строками. Наоборот, я склеил, чтобы и этот вариант проверить.

По вашим ссылкам смотрел, сам многие из них находил. Но что-то пока они не помогли разобраться.

Повторюсь, проблема наблюдается только из-под одного пользователя. Если бы было что-то с hosts или dns, наблюдалось бы и у других пользователей.

Вот содержимое /etc/resolv.conf:

nameserver 127.0.0.53
options edns

Повторюсь, проблема наблюдается только из-под одного пользователя. Если бы было что-то с hosts или dns, наблюдалось бы и у других пользователей.

Ну мне кажется, что все равно дело где-то с таймаутом DNS. А чем этот пользователь от других отличается? Я уже видел, что этот пользователь создан при помощи useradd. А другие пользователи как создавались? Откуда они? Проблема прав, может быть?

У тебя Mint. Значит, это производная Debian. Создай пользователя при помощи adduser, а не useradd, и проверь снова.

adduser  и  addgroup добавляют пользователей и группы в систему, исходя
из параметров, заданных  в  командной  строке  и  информации  из  файла
/etc/adduser.conf.   Они   являются   дружественными   интерфейсами   к
программам groupadd  и  usermod,  выбирают  согласованные  с  политикой
Debian  значения  UID  и  GID,  создают  домашний  каталог с начальными
настройками,  запускают  определённый  сценарий,  и  обладают   другими
возможностями.

Прям разозлился, что аж Mint установил. Но не могу воспроизвести.

Явно же смущает:

/bin/sh: 2: Syntax error: Bad fd

Вы точно никаких «тем» zsh не устанавливали? Уж больно подозрительное у вас там что-то пытается нарисоваться в строке приглашения, нестандартное.

Такое впечатление, что этот precmd() пытается вызвать сценарий, рассчитанный на zsh, но вызывается dash, отваливается с ошибкой, а дальше уже получается таймаут из-за того, что вот эту ошибку (сам текст её) оно пытается искать в ваших hosts.

Ну... я бы так перевёл. Но, осторожно, у меня богатая фантазия.

Сделай Ctrl + Alt + F2 , далее логин пользователем и запуск mc. Если запуск быстрый, то трабла связана с X. Можно использовать mc --no-x11 .

аж Mint установил. Но не могу воспроизвести

Воспроизвёл.
Стыдно признаться, но всё что тут понаписано мной про zsh - ерунда полная. Абсолютная.

Поведение mc ровно как у вас, если у пользователя оболочка /bin/dash.

Самым простым решением будет вам - поменять оболочку для этого пользователя на /bin/bash.

простым решением будет

Потому что «сложным решением» пока вообще даже фантазия не помогает, что можно сделать.

На текущий момент так:

В Ubuntu, Mint, ArchLinux - все с ядром 5.4 если запускать так:

SHELL=/bin/dash mc

В Debian с ядром 5.4 из бэкпортов - задержки нет.

Задержка эта живёт в коде /mc/src/subshell/common.c

   /* we wait up to 10 seconds if fail_on_error, forever otherwise */
    wtime.tv_sec = 10;
    wtime.tv_usec = 0;
    wptr = fail_on_error ? &wtime : NULL;

        if (select (maxfdp + 1, &read_set, NULL, NULL, wptr) == -1)

Почему этот select работает нормально в Debian, но зависает и отваливается по таймауту в остальных при subshell=DASH - никаких мыслей нет.

Надо звать настоящих программистов за разъяснениями.

Поведение mc ровно как у вас, если у пользователя оболочка /bin/dash.

ТС пишет, что он создавал пользователя при помощи useradd. В Debian этот способ прописывает SHELL как /bin/sh или пустую строчку, если специально не указать --shell в командной строке.

 -s, --shell ОБОЛОЧКА
           Имя регистрационной оболочки пользователя. По умолчанию это поле
           пусто, что вызывает выбор регистрационной оболочки по умолчанию
           согласно значению переменной SHELL из файла /etc/default/useradd,
           или по умолчанию используется пустая строка.

$ grep SHELL /etc/default/useradd
# The SHELL variable specifies the default login shell on your
SHELL=/bin/sh

Однако даже если прописывается /bin/sh, то странно: у меня в Debian (а что в Mint, надо проверить):

$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 июн  9  2015 /bin/sh -> bash

Если создавать пользователя при помощи adduser (а именно так рекомендуется делать https://wiki.debian.org/UserAccounts), то SHELL прописывается так, как он указан в /etc/adduser.conf, а по умолчанию в Debian там стоит прямо конкретно /bin/bash.

$ grep SHELL /etc/adduser.conf 
# The DSHELL variable specifies the default login shell on your
# system.
DSHELL=/bin/bash

Достаточно проверить переменную SHELL. dash используется в Debian как non-interactive shell, а пользовательская оболочка по умолчанию bash. https://wiki.debian.org/Shell

UPD. Вот как раз может быть, что в Mint /bin/sh на /bin/dash указывает.

Всё правильно. adduser это обёртка над более суровым useradd. Кабы ТС пользователя добавлял этой обёрткой - был бы bash.

Вот свежеустановленный (позавчера) Mint:

novas@novas-VirtualBox:~$ ls -la /bin/sh
lrwxrwxrwx 1 root root 4 Dec 27 01:37 /bin/sh -> dash

Поэтому через useradd ТС получил пользователя с dash.

Поэтому и в трассировке ругань на /bin/sh, который dash. (Но я ошибся - эта ругань совершенно безобидная и не должна была смущать.)

Тут вроде всё просто и понятно. Вот с select - не понятно.

dash используется в Debian как non-interactive shell, а пользовательская оболочка по умолчанию bash

Вот свежеустановленный (с неделю назад) Debian10:

bo@debian:~$ ls -la /bin/sh
lrwxrwxrwx 1 root root 4 дек 15 17:24 /bin/sh -> dash

У всех дебианов по-умолчанию должен быть dash. Всегда так было.

Вот с select - не понятно.

Ненаучным тыком - разница между Arch и Ubuntu/Mint:

При SHELL=/bin/dash mc

На tty2 Ubuntu/Mint также зависает на 10 секунд, как и из DE.

А вот Arch - не(!!!) зависает на tty2. Только в эмуляторе терминала DE.

У всех дебианов по-умолчанию должен быть dash. Всегда так было.

Не знаю, не помню, когда это произошло, но дело в том, что у меня Debian обновляется еще со времен pre-Etch (если судить по самым старым файлам, то 2005 год), то есть когда Etch еще не вышел. С тех пор заново я ничего не ставил, а просто накатывал. Поэтому у меня ситуация может оказаться вот такой, какая она есть. Я не помню, когда dash стал по умолчанию. Вроде в Ubuntu он по умолчанию стал только с версии 6.10. Значит, в 2006 году. И не помню что-то, чтобы я менял этот линк.

Возможно я погорячился с «Всегда так было».

Честнее сказать «Всегда только так и видел». Сейчас максимально старый - Debian6 в виртуалке запустил. Там тоже dash.

Что было до squeeze не знаю.

Возможно я погорячился с «Всегда так было».

Я вот сейчас запустил dpkg-reconfigure dash и он мне предложил заменить /bin/sh в dash, но можно отказаться. Видимо, он когда-то давно тоже предлагал, но я не согласился. Этого я уже не помню. При обновлении на последний stable ничего такого точно не было.

Почему этот select работает нормально в Debian, но зависает и отваливается по таймауту в остальных при subshell=DASH - никаких мыслей нет.

Откуда ошибка идет там более-менее понятно. В исходном коде mc какая-то фигня (/src/subshell/common.c). Там в subshell, если он является dash, передается pwd>&%d, чтобы prompt сформировать. Вместо %d подставляется subshell_pipe[WRITE]. dash на этот subshell_pipe[WRITE] выдает ошибку типа:

$ dash -c 'pwd>&10'
dash: 1: Syntax error: Bad fd number

Скорее всего, файловый дескриптор, который передается в скрипт, состоит из двух цифр, а dash их не понимает. Похоже, он только от 0 до 9 принимает.

$ dash -c 'pwd>&9'
dash: 1: 9: Bad file descriptor

В общем, subshell умирает раньше времени из-за ошибки, не дойдя до конца. А mc сидит в select с тамаутом 10 секунд.

Спасибо. Вполне похоже на правду.

Я по старой рабоче-крестьянской привычке тупо принтов в код навставлял. В смысле - принтов в файл-лог. Поэтому сомнений-то нет в месте затыка.

DASH: 1609159443244499 | 8 | iter=6 - maxfdp=9 (1)
DASH: 1609159453251255 | 10006756 | iter=6 - maxfdp=9 (3)

Сейчас попробую в коде зашитое приглашение для dash поменять.

Всё это привело к тому, что теперь в одной системе порт 53 может слушать несколько разных ресолверов, причём для избежания конфликтов NetworkManager и systemd-resolved используют вместо 127.0.0.1 другие IP-адреса в loopback-сети:

127.0.0.1 — стандартный dnsmasq, Unbound или knot-resolver с настройками по умолчанию;
127.0.1.1 — dnsmasq или Unbound, запущенный NetworkManager'ом и управляемый через D-Bus;
127.0.0.53 — systemd-resolved.

Проблема заключается в том, что с systemd NetworkManager пытается дружить сильнее разумного:

если NM видит, что в системе установлен systemd-resolved, то автоматически использует его, не проверяя, включен тот или выключен;
из-за этого вместо адресов настоящих DNS в resolv.conf попадает 127.0.0.53.

тут https://cdnnow.ru/blog/dnslocal/

Скорее всего, файловый дескриптор, который передается в скрипт, состоит из двух цифр, а dash их не понимает. Похоже, он только от 0 до 9 принимает.

Всё так. Добавил в свой лог запись значения subshell_pipe[WRITE] во время формирования строки приглашения.

Запускаю этот самосборный mc с принтами в ArchLinux так:

$SHELL=/bin/dash /usr/local/bin/mc

• Если запускать из эмулятора терминала - там 10, и висит до таймаута.
• Если запускать из tty2 - там 9, и нормально стартует.
• Если убрать из исходников «pwd>&%d;», то висит в любом случае - хоть 10, хоть 9 в subshell.

Если убрать из исходников «pwd>&%d;», то висит в любом случае - хоть 10, хоть 9 в subshell.

В случае ошибки ни один байт не попадает в subshell_pipe[WRITE], так как pwd валится из-за ошибки fd. И в случае отсутствия команды pwd тоже ничего в subshell_pipe[WRITE] не попадает. Ни одного байта. А mc, похоже, хоть чего-то там ждет максимум 10 секунд.

Ради любопытства - перезагрузился в свой Debian (который не виртуальный, настоящий, с KDE) - там и в эмуляторе konsole, и в tty2 subshell_pipe[WRITE] = 9. Потому и с dash проблем там нет.

Забавно, наверное что-то про GNOME(xfce4, cinnamon - не суть) тогда это 10.

Пойду, попытаюсь нарыть откуда в гномах берётся 10 в subshell_pipe.

Окончательно «всё, наигрался»:

В коде mc SHELL_DASH можно сделать по аналогии с SHELL_TCSH, через mkfifo и перенаправлять pwd не в номер файла, а в имя этого канала (как и у tcsh опять же).

Кажется всё нормально работает.

В реальной жизни скорее всего это никому не нужно. Но так, в порядке просвещения - это было занимательно.

ТСу, конечно, просто поменять shell на /bin/bash у проблемного пользователя.

То, что там fd больше 9, никакой ошибки нет. Проблема, да, в самом скрипте. Не учли эту особенность dash [1]. Понятно, что тут только однострочник надо как-то переделывать, потому что нельзя было рассчитывать, что dash должен съесть fd больше 9. Скорее всего, у того, кто скрипт закоммитил, просто не проявился баг.

В реальной жизни скорее всего это никому не нужно. Но так, в порядке просвещения - это было занимательно.

Полезный выход из этой истории — поискать похожий баг в багзилле mc или зарепортить, приложив патч. Учитывая, что dash вообще редко у кого является интерактивным шеллом, по ошибке если только. А среди тех, у кого он оказался оболочкой по умолчанию, не нашлось людей, которые стали разбираться или могли это сделать. Скорее, просто забили или поменяли SHELL потом.

[1] На самом деле, это допустимая трактовка POSIX. Не обязаны.

https://pubs.opengroup.org/onlinepubs/007904875/utilities/xcu_chap02.html#tag...

Open files are represented by decimal numbers starting with zero. The largest possible value is implementation-defined; however, all implementations shall support at least 0 to 9, inclusive, for use by the application. These numbers are called «file descriptors»