Solved MC Midnight Commander slow start

I have a weird problem. Today I reinstalled FreeBSD 13 RC4, this time on a UEFI boot disk. Last week I had it installed on a legacy boot system. It is exactly the same config with exactly the same programs installed. The system is running fine. However, MC takes now 5 seconds to start (in a xfce terminal). This did not happen last week. MC was fast. Since the only thing that has changes is the boot method I wonder if that can have something to do with it. It is far fetched but I have no idea why this has started happening. The pkg number is the same. Running the latest packages. Any ideas?
 
I doubt that. Maybe something in the mc's history is bothering it ? In your home you have ~/.config/mc directory. Try to rename it to old ( mv ~/.config/mc ~/.config/mc.old ) and try to launch mc again.
 
I’ll try both suggestions tomorrow. I’ll come back to it. Thanks.

update: I've removed .local/share/mc and .config/mc and all is well :)
 
I have the same issue. truss output:

Code:
0.169512074 write(1,"\^[[1;1H  Left     File     Comm"...,4096) = 4096 (0x1000)
0.169561431 write(1,"5m\^[[48;5;4m/.config-nextstep  "...,1173) = 1173 (0x495)
0.169589289 select(6,{ 5 },0x0,0x0,{ 0.000000 }) = 0 (0x0)
0.169618566 sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0)
0.169639519 sigaction(SIGINT,{ 0x80084b000 SA_SIGINFO ss_t },{ SIG_IGN 0x0 ss_t }) = 0 (0x0)
0.169660500 sigprocmask(SIG_SETMASK,{ },0x0)     = 0 (0x0)
2.517891736 select(8,{ 4 7 },0x0,0x0,0x0)     = 1 (0x1)
2.518333016 sigprocmask(SIG_SETMASK,{ SIGHUP|SIGINT|SIGQUIT|SIGILL|SIGTRAP|SIGABRT|SIGEMT|SIGFPE|SIGKILL|SIGBUS|SIGSEGV|SIGSYS|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0)
2.518686266 sigaction(SIGINT,{ SIG_IGN 0x0 ss_t },{ 0x80084b000 SA_SIGINFO ss_t }) = 0 (0x0)
2.518815420 sigprocmask(SIG_SETMASK,{ },0x0)     = 0 (0x0)

Looks like it starts to draw menu and then pauses on sigprocmask(). Removed config directories, but it still pauses for me.
 
blackhaz Note that it's the select() after sigprocmask() that caused delay, not the sigprocmask itself. I tested it myself and on FreeBSD I do have this delay too. If I trace it mc starts immediately.
I dug around and found the select() in question is comming from subshell, read_command_line_buffer(), in the src I shared line 542.

mc -u doesn't have this problem ; I guess it works then as expected.
FYI: there are some nice mc faqs worth checking too.
 
blackhaz Note that it's the select() after sigprocmask() that caused delay, not the sigprocmask itself. I tested it myself and on FreeBSD I do have this delay too. If I trace it mc starts immediately.
I dug around and found the select() in question is comming from subshell, read_command_line_buffer(), in the src I shared line 542.

mc -u doesn't have this problem ; I guess it works then as expected.
FYI: there are some nice mc faqs worth checking too.
Same issue in FreeBSD 14 - If I try and run under truss to see whats going on, the delay goes away, and if I disable with subshell support disabled (-u) it fixes it... To make things even more bizarre, its only happening on a system I use for a desktop - I have a server that is also on v14 and if I start the app via an SSH session, it fires up instantly.

Did you ever get to the bottom of what specifically about subshell support causes this?
 
Did you ever get to the bottom of what specifically about subshell support causes this?
I don't remember exactly but as OP didn't reply to my thread then I guess I didn't pay any more attention to it.

If I try and run under truss to see whats going on, the delay goes away
You could use two terminal sessions to trace this. In the first one do the echo $$ to get its PID and trace it with the truss -fp $pid in the other to trace it. That will avoid messing up the session within the same session.

o make things even more bizarre, its only happening on a system I use for a desktop
Did you make sure DISPLAY var is set properly ? This can cause delays too (faq item).
 
You could use two terminal sessions to trace this. In the first one do the echo $$ to get its PID and trace it with the truss -fp $pid in the other to trace it. That will avoid messing up the session within the same session.
This had an interesting outcome. Doing that with truss caused it to just hang
Code:
2793: read(0,"\\",1)                            = 1 (0x1)
 2793: pselect(0x1,0x820eabdf0,0x0,0x820eabd70,0x820eabd10,0x0) = 1 (0x1)
 2793: pselect(0x1,0x820eabc90,0x0,0x0,0x0,0x822007b9c) = 1 (0x1)
 2793: read(0,"w",1)                             = 1 (0x1)
 2793: pselect(0x1,0x820eabdf0,0x0,0x820eabd70,0x820eabd10,0x0) = 1 (0x1)
 2793: pselect(0x1,0x820eabc90,0x0,0x0,0x0,0x822007b9c) = 1 (0x1)
 2793: read(0,"\\",1)                            = 1 (0x1)
 2793: pselect(0x1,0x820eabdf0,0x0,0x820eabd70,0x820eabd10,0x0) = 1 (0x1)
 2793: pselect(0x1,0x820eabc90,0x0,0x0,0x0,0x822007b9c) = 1 (0x1)
 2793: read(0,"$",1)                             = 1 (0x1)
 2793: pselect(0x1,0x820eabdf0,0x0,0x820eabd70,0x820eabd10,0x0) = 1 (0x1)
 2793: pselect(0x1,0x820eabc90,0x0,0x0,0x0,0x822007b9c) = 1 (0x1)
 2793: read(0," ",1)                             = 1 (0x1)
 2793: pselect(0x1,0x820eabdf0,0x0,0x820eabd70,0x820eabd10,0x0) = 1 (0x1)
 2793: pselect(0x1,0x820eabc90,0x0,0x0,0x0,0x822007b9c) = 1 (0x1)
 2793: read(0,"'",1)                             = 1 (0x1)
 2793: pselect(0x1,0x820eabdf0,0x0,0x820eabd70,0x820eabd10,0x0) = 1 (0x1)
 2793: pselect(0x1,0x820eabc90,0x0,0x0,0x0,0x822007b9c) = 1 (0x1)
 2793: read(0,"\n",1)                            = 1 (0x1)
 2793: write(2,"PS1='\\u@\\h:\\w\\$ '",17)       = 17 (0x11)
 2793: write(2,"\n",1)                           = 1 (0x1)
 2793: write(2,"\^[[?2004l\r",9)                 = 9 (0x9)
<hung at this point and had to do a 'killall mc' to end it>
Seems it doesn't want to be caught with its pants down by truss. lol.
Did you make sure DISPLAY var is set properly ? This can cause delays too (faq item).
The FAQ suggests unsetting this in case that is the issue (connection to X server is blocked by a firewall and can cause a hang), didn't help sadly.

I found something interesting, my local user has its shell set to bash (/usr/local/bin/bash) -- if I set it to csh, the problem goes away:
Code:
[me@bsd-desktop ~]$ csh
me@bsd-desktop:~ % echo $SHELL
/usr/local/bin/bash
me@bsd-desktop:~ % which csh
/bin/csh
me@bsd-desktop:~ % setenv SHELL /bin/csh
As soon as I did that, it fired up instantly and I didn't need to use -u to disable subshell support. This also explains why I don't have the issue with it when using SSH to my server, I SSH in as root, whos shell is csh..

Bizarre - So something about using bash as the shell is causing it.
 
Maybe something uncommon in your .bashrc?
I don't have a .bashrc Its a stock install of bash (just installed the package and haven't created any .bashrc file in my home directory). The only file I see relating to bash in my home directory is the .bash_history file.
 
Bizarre - So something about using bash as the shell is causing it.
That is indeed interesting. I wonder why is bash stalling the start like this.
I'm on 4-week vacation, I'm not touching any systems, code or looking at any source code during this period. ;) The only router I'm touching is the woodworking one. :)
 
blackhaz Note that it's the select() after sigprocmask() that caused delay, not the sigprocmask itself. I tested it myself and on FreeBSD I do have this delay too. If I trace it mc starts immediately.
I dug around and found the select() in question is comming from subshell, read_command_line_buffer(), in the src I shared line 542.

mc -u doesn't have this problem ; I guess it works then as expected.
FYI: there are some nice mc faqs worth checking too.
I have the same problem.
Installed FreeBSD to generate PGP certificates. Installed MC. And I immediately noticed the very long startup of MC. I have a computer with Debian. The MC starts instantly on it.
mc -u solves the problem.

Code:
user-0001@PGP ~ % env

_=/usr/bin/env
OLDPWD=/home/user-0001/pgp2
PWD=/home/user-0001
COLORTERM=yes
LESS_TERMCAP_us=
LESS_TERMCAP_ue=
LESS_TERMCAP_so=
LESS_TERMCAP_se=
LESS_TERMCAP_me=
LESS_TERMCAP_md=
LESS_TERMCAP_mb=
CLICOLOR=1
PAGER=less
EDITOR=vi
SHLVL=1
USER=user-0001
LOGNAME=user-0001
HOME=/home/user-0001
MAIL=/var/mail/user-0001
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/user-0001/bin
TERM=xterm
BLOCKSIZE=K
MM_CHARSET=UTF-8
LANG=C.UTF-8
SHELL=/usr/local/bin/zsh
SSH_CLIENT=10.0.100.4 58216 22
SSH_CONNECTION=10.0.100.4 58216 10.0.100.7 22
SSH_TTY=/dev/pts/0
 
This is understandable. But I don’t know how to solve the long startup problem.

Your shell seems to be zsh - I have this problem with bash... I don't experience the issue if the user's shell is csh - I don't understand why it behaves this way for me either..

Can you see if setting your users shell to csh fixes it for you?
 
Your shell seems to be zsh

Yes.

I have this problem with bash...

Yes.

I don't experience the issue if the user's shell is csh - I don't understand why it behaves this way for me either..

Yes, I read it.

Can you see if setting your users shell to csh fixes it for you?

I have a problem in both Bash and Zsh.
There's no point in installing CSH for me. I don't use it.
This is a treatment for headaches by removing the head.
I looked on the Internet. I haven't found a solution to the problem yet.
 
csh is in the base, you don't need to install it. But I agree, that's not a solution to a problem but rather an observation.

It's an interesting issue. I tried to have a quick look into it on FreeBSD 14 (4.8.30) and Debian 12.4 (4.8.29). Version mismatch doesn't matter, we observed this issue for some time now with various versions.

This is what I did:
o) modified src/subshell/common.c so it gives me more verbose information on what is happening
o) tested with root's shell csh and bash for comparison (full logout before starting mc)

This is what I observed
o) there's no delay with csh because read_command_line_buffer () is not executed on startup at all
o) both csh/bash have the same stty settings
o) delay is happening due to the select() here at line 570: src/subshell/common.c:L#570, select has now timeout set to 1sec.
In Linux this select() doesn't take so long; it does under FreeBSD​

o) starting mc in loop (mc, exit, mc, exit, mc, exit .. ) doesn't yield the same results.
This select() in loop with 1sec timeout keeps failing either with errno 2(ENOENT) or errno 4 (EINTR). errno 4 is something I understand but I don't know what's happening with errno 2 (race condition during start?). But as this is happening also under Linux I didn't pay much attention to it​

So basically that 1s timeout is what is causing delay under FreeBSD. I didn't dig deep why is csh not using this at all (during startup; during usage I had trouble triggering that function even when I used subshell). Setting this timeout to 0sec sometimes works (mc starts up immediatelly), sometimes it gets stuck during startup and actually starts without proper mc profile (not shell profile, mc profile). I know that time in select() "can lengthen the interval by an indeterminate amount" too.
 
Back
Top