piknew Posted June 24, 2018 Posted June 24, 2018 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 Posted June 24, 2018 Author Posted June 24, 2018 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 Posted June 24, 2018 Posted June 24, 2018 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 Posted June 24, 2018 Posted June 24, 2018 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 Posted June 25, 2018 Author Posted June 25, 2018 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 Posted June 25, 2018 Author Posted June 25, 2018 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_krb5bonding 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 Posted June 25, 2018 Posted June 25, 2018 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 Posted June 25, 2018 Author Posted June 25, 2018 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&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 Posted June 25, 2018 Posted June 25, 2018 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.
Recommended Posts