Startup delay when running the "less" program

Support
,
1

Hello,

I have [Searched] the forum for my issue and found nothing related or helpful
I have checked the [Resources category]
I have reviewed the [Wiki] for relevant information
I have read the the [Release Notes and Errata]

OpenMandriva Lx version:

OpenMandriva Lx 25.06 (ROME) with kernel 6.14.2

Desktop environment (KDE, LXQT…):

KDE plasma

Description of the issue (screenshots if relevant):

I use the “less” command frequently in a terminal window to examine the content of text files.

Every time I use the “less” command there is a delay of approximately 2.3 seconds before anything appears on the screen. I understand that “less” scans the whole file to find newlines before starting the display. However the 2.3 second delay still happens even when I use it to display the content of a very small file.

Relevant information (hardware involved, software version, logs or output…):

For example, my .bashrc file is a small 11 line, 234 byte file, unchanged since the user-id was created. The same delay does not happen when using the similar “more” command. Here are some timing results comparing the times to run “less” and “more”. I keep pressing “q” so that “less” exits as soon as the first keyboard character is read by the program.

[xxxxxx ~]$ time less .bashrc

real 0m2.316s
user 0m0.147s
sys 0m0.067s

[xxxxxx ~]$ time more .bashrc >/dev/null

real 0m0.009s
user 0m0.005s
sys 0m0.004s

The “more” command uses the same shared libraries as the “less” command plus a few others. The starting delay is consistent in subsequent runs of the program when the files should all be in file cache. Running the “top” program shows only a tiny CPU and memory usage on this machine at the time of the tests.

I am running OpenMandriva Lx 25.06 (ROME) with kernel 6.14.2 and KDE plasma desktop. It is an x86_64 system. The CPU is not the latest and fastest (an Intel E5-1620 at 3.50GHz). The system drive is a reasonably fast SATA SSD. The machine also has plenty of RAM (86 GiB) to act as a file cache.

I have also tried running the program in a console text display (no GUI) and the startup delay is the same.

The version of the “less” program on OpenMandriva Lx 25.06 (ROME) is 676.

I also have Debian 12 installed on another SSD in this machine. The version of “less” on this SSD is 590 and it does not experience this starting delay.

I also have Debian 13 installed on another SSD in this machine. The version of “less” on this SSD is 668 and it also does not experience this starting delay.

Has anyone else experienced this delay issue when running the “less” command and can anyone suggest a fix ?

2

My guess is that there is some unforeseen difference in how ‘less’ was compiled since OM uses clang instead of gcc and the much newer kernel in OM may also be expecting certain instruction sets the older CPU does not have. One last possibility is how OM may have handled Spectre/Meltdown mitigations vs Debian. I think you have just stumbled across the perfect storm.

3

I ran the same commands and it isn’t even close to what you are getting.

[studebakerguy tmp]time less ~/.bashrc >/dev/null

real	0m0.309s
user	0m0.187s
sys	0m0.123s
[studebakerguy tmp]time more ~/.bashrc >/dev/null

real	0m0.007s
user	0m0.003s
sys	0m0.004s
[studebakerguy tmp]

Try running the following and post the results. It might give us an idea of what its doing in those two seconds.

strace --timestamps less ~/.bashrc > /dev/null

You may need to install strace.

And, welcome to OpenMandriva

4

Here is a portion of the strace with actions either side of the 2 second delay. It looks like the “Inappropriate ioctl for device” error on TCGETS might be the cause of the 2 second delay. My hardware is a 10+ years old design (a HP Z440 workstation) but I would think the keyboard input hardware is fairly generic. I will try again later today with a ssh login session and report the trace result I get with that session.

07:13:48 pipe2([3, 4], O_CLOEXEC)       = 0
07:13:48 prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024, rlim_max=512*1024}) = 0
07:13:48 prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=1024, rlim_max=512*1024}) = 0
07:13:48 mmap(NULL, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f0967656000
07:13:48 rt_sigprocmask(SIG_BLOCK, ~[], [], 8) = 0
07:13:48 clone3({flags=CLONE_VM|CLONE_VFORK|CLONE_CLEAR_SIGHAND, exit_signal=SIGCHLD, stack=0x7f0967656000, stack_size=0x9000}, 88) = 2561
07:13:48 munmap(0x7f0967656000, 36864)  = 0
07:13:48 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
07:13:48 close(4)                       = 0
07:13:48 fcntl(3, F_SETFD, 0)           = 0
07:13:48 read(3, qqqqqq"\33", 1)              = 1
07:13:50 ioctl(3, TCGETS, 0x7ffdd362eb40) = -1 ENOTTY (Inappropriate ioctl for device)
07:13:50 fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
07:13:50 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
07:13:50 write(1, "\33", 1)             = 1
07:13:50 read(3, "[38;5;4;1m# .bashrc\n\n\33[38;5;4;1m"..., 8191) = 386
07:13:50 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
07:13:50 write(1, "[38;5;4;1m# .bashrc\n\n\33[38;5;4;1m"..., 386) = 386
07:13:50 read(3, "", 7805)              = 0
07:13:50 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2561, si_uid=1000, si_status=0, si_utime=0, si_stime=0} ---
07:13:50 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
5

Actually the “Inappropriate ioctl for device” error appears to be irrelevant.

I can run the “less” program executable from Debian 13 on the OpenMandriva system and get the same error on the ioctl and no 2 second delay.

08:08:52 prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
08:08:52 munmap(0x7ffa2a191000, 198619) = 0
08:08:52 ioctl(1, TCGETS, 0x7ffc33552610) = -1 ENOTTY (Inappropriate ioctl for device)
08:08:52 getrandom("\x47\xe0\xa7\x81\x02\x3e\x1a\x83", 8, GRND_NONBLOCK) = 8
08:08:52 brk(NULL)                      = 0x5630071ef000

The ioctl with this program version is on fd 1 instead of fd 3 but I do not think this is relevant.

Update:

I made an interesting discovery.

The 2 second delay only happens when the output of the “less” program is being displayed with text colours for syntax highlighting. If the file being displayed has no recognised syntax information (such as the README file from the program source) then there is no 2 second delay.

If I unset the LESS environment variable to disable colour rendering then there is no 2 second delay. The default LESS environment variable setting on OpenMandriva is LESS=-R

I tried compiling the latest source of the “less” program on both OpenMandriva and Debian. On Debian, setting LESS=-R has no effect. The file content is always displayed without colour syntax highlighting. This explains why I did not encounter the delay on that system.

My TERM environment variable is xterm-256color and my LANG environment variable is en_GB.UTF-8 on both operating systems.

As the source code I compiled is the same on both operating systems the difference in behaviour must be due to the different libraries used (libncursesw.so.6 vs libtinfo.so.6)

Buy why this behaviour only happens on my machine is a mystery.

Here are the libraries being used on each system.

Running on OpenMandriva (colour syntax highlighting supported):

Program version 678 compiled with clang version 19.1.7-1
ldd ./less
	linux-vdso.so.1 (0x00007fc2c64c9000)
	libncursesw.so.6 => /lib64/libncursesw.so.6 (0x00007fc2c63f5000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fc2c6200000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fc2c64cb000)

Running on Debian (colour syntax highlighting not supported):

Program version 678 compiled with clang version 19.1.7 (3)
ldd ./less
	linux-vdso.so.1 (0x00007f8b7360d000)
	libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f8b7356b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8b73375000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8b7360f000)
6

This is interesting and really confusing. Less doesn’t really do much so it doesn’t make much sense that it would take so long. Your thought of the library difference seems reasonable, but it’s hard to say for sure.

7

The problem appears to be with the shell script /usr/bin/lesspipe.sh which is referred to by the LESSOPEN environment variable.

On my machine if I run this script with a filename argument there is the 2.3 second delay before the script produces any output.

If I unset the LESSOPEN environment variable then the delay when running “less” no longer occurs, but the display output is no longer colourised.

I will try to work out why /usr/bin/lesspipe.sh produces a delay, but like many shell scripts it is quite difficult to decode it’s logic.

lesspipe.sh runs a perl script vimcolor which constructs a script for vim and runs vim to execute that script.

The delay is while vim runs the script.

I think this is as far as I want to go. I will forego the colourised syntax highlighting to avoid the startup delay.

1 Like