apt list vs mainline (very slow)

[piknew]

After upgrade two of my boards to mainline (4.14.51-sunxi) I have noticed that simple command

 

apt list

 

basically stopped working. It stuck at "Listing ..." (at this  moment 1 core of CPU is utilized in 100%). Now I run it in background to see if eventually it will be completed... So far (15 minutes)... nothing.

 

apt list --installed

 

is also very slow, but after some time it gives results. However, it is much slower than on "default" (3.4.113-sun8i)

 

Can anybody check it and reconfirm?

 

[piknew]

Actually I have found root cause of this slowness. It is a file:

 

/etc/apt/apt.conf.d/02-armbian-compress-indexes

 

After removing it - everything is very fast again. So, the issue is rather not related to kernel. It is related to Armbian support files (in my case the version is 5.47).

 

[Igor]

39 minutes ago, piknew said:

After removing it - everything is very fast again. So, the issue is rather not related to kernel. It is related to Armbian support files (in my case the version is 5.47).

Good catch. This comes with new BSP rework. Will be investigated further.

Can you provide armbianmonitor -u from one of those?

[Igor]

1 hour ago, piknew said:

After upgrade two of my boards to mainline (4.14.51-sunxi) I have noticed that simple command

Can't reproduce. http://ix.io/1eFh Works fast as expected.  

cat /etc/apt/apt.conf.d/02-armbian-compress-indexes
Acquire::GzipIndexes "true";
Acquire::CompressionTypes::Order:: "gz";

 

[piknew]

Please see attached log.txt.

 

This is the sequence of operations to reproduce (on my Orange Pi+2 in this case). Important is that removal or restore of /etc/apt/apt.conf.d/02-armbian-compress-indexes file shall be followed by apt update command.

 

Result of armbianmonitor -u is here.

 

Edit 1: my Opi+2 just "died" (this part of post shall be probably moved to new topic I guess). Igor, can you please try following? I was able to "make unresponsible" my both Opi+ and now OpiZero:

 

Starting point - armbian-hardware-monitor was disabled wg. no related symlink in /etc/systemd/.... // Please do not ask why I disabled it . Enabling it was caused by message in armbianmonitor -u - so, next is what I did.

 

root@PKOTHER:~# systemctl enable armbian-hardware-monitor
Created symlink from /etc/systemd/system/basic.target.wants/armbian-hardware-monitor.service to /lib/systemd/system/armbian-hardware-monitor.service.
root@PKOTHER:~# systemctl start armbian-hardware-monitor
root@PKOTHER:~# systemctl stop armbian-hardware-monitor

 

Interesting thing is that "PuTTY" is keeping connection (by means of TCP?) // as it is seen first I was trying to connect to "pkhelper" (OPi+2 which stop responding after commands as given above and is a subject of my my tests for armbiuanmonitor -u):

 

 

Last command  was not completed. And device... in not accessible anymore. I was able to reproduce it wit both OP'is.

 

admin@PKSERVER:~$ ssh root@pkother
ssh: connect to host pkother port 22: No route to host

 

Edit 2: now both of my "servers" are restarted, so I can resume testing...

[piknew]

For the issue "systemctl stop armbian-hardware-monitor" - the reason is quite obvious, this line of script /usr/lib/armbian/armbian-hardware-monitor:

 

/sbin/modprobe -r $(cut -f1 -d' ' </proc/modules)

 

In my case (hint: removing network/binding modules is basically "showstopper"):

 

root@PKHELPER:~# cut -f1 -d' ' </proc/modules
rpcsec_gss_krb5
bonding
snd_soc_hdmi_codec
rc_cec
dw_hdmi_i2s_audio
dw_hdmi_cec
evdev
8189es
sun8i_dw_hdmi
dw_hdmi
cec
sun8i_codec_analog
snd_soc_simple_card
sun4i_codec
sun4i_i2s
snd_soc_simple_card_utils
ir_lirc_codec
lirc_dev
snd_soc_core
rtc_ds1307
sunxi_cir
snd_pcm_dmaengine
cfg80211
snd_pcm
snd_timer
snd
rfkill
soundcore
sun4i_gpadc_iio
sun4i_tcon
sun8i_mixer
sun4i_drm
uio_pdrv_genirq
uio
fuse
uas
pwrseq_simple
sy8106a_regulator
realtek

 

[Igor]

5 minutes ago, piknew said:

hint: removing network/binding modules is basically "showstopper"

Don't worry about that. It works as expected. When you are shutting the board down ... you don't need this. I think it's written in the script why modules are unloading.

 

If you are messing with startup services, a warranty is void  Until this is not replicated on a clean system, a problem does not exist.

 

We pay attention. 

[piknew]

9 minutes ago, Igor said:

Don't worry about that. It works as expected. When you are shutting the board down ... you don't need this. I think it's written in the script why modules are unloading. 

  

If you are messing with startup services, a warranty is void  Until this is not replicated on a clean system, a problem does not exist. 

  

We pay attention. 

 

Sure. I will treat it as warning - do not use "stop" for this service. If there is relable way to recognise if "stop" is done on behalf of shutdown then it would be good idea to add it here as condition... I guess it is EOT for this "issue".

 

 

How about the test that I've done here: https://forum.armbian.com/topic/7548-apt-list-vs-mainline-very-slow/?do=findComment&amp;comment=56805

I can repeat it, however as "apt" itself is a binary - I do not know what is really done by this tool here (no child processes, eg gzip etc.)...

[Igor]

3 minutes ago, piknew said:

I can repeat it

Until I can't, don't have any logical explanation and there are no other reports ... it can be due to problems on your side. Let's wait for a while.