lfam Posted June 12, 2015 Share Posted June 12, 2015 The script /etc/init.d/armhwinfo is executed on boot and gathers information about the machine's capabilities to tweak some settings. On my Cubieboard2 running Debian Jessie, it sometimes takes up to 20 seconds to execute. For example, last boot: $ systemd-analyze critical-chain multi-user.target @30.700s └─armhwinfo.service @12.831s +17.867s └─basic.target @12.155s └─timers.target @12.130s └─systemd-tmpfiles-clean.timer @12.130s └─sysinit.target @12.097s └─networking.service @4.315s +7.732s └─systemd-random-seed.service @3.979s +112ms └─systemd-remount-fs.service @3.672s +286ms └─keyboard-setup.service @2.272s +1.379s └─systemd-udevd.service @2.175s +35ms └─systemd-tmpfiles-setup-dev.service @2.012s +75ms └─kmod-static-nodes.service @1.732s +186ms └─system.slice @1.290s └─-.slice @1.033s I'd like to improve this situation. My first question: is the script idempotent? By which I mean, is there any harm in running it over and over again while I figure out which steps are taking soooooo long? Link to comment Share on other sites More sharing options...
Igor Posted June 13, 2015 Share Posted June 13, 2015 You can run this script numerous times - it only reads various system information and sets: /var/run/machine.id and /var/run/motd.dynamic Nothing unusual. I would also like to fix those systemd issues , once for all I am running just few extra stuff and the system is really minimal . The behavior is strange and I am not sure whether my scripts are done badly or is the systemd the one which makes troubles. Link to comment Share on other sites More sharing options...
lfam Posted June 13, 2015 Author Share Posted June 13, 2015 It also writes to the sysfs, setting the block IO scheduler. Anyways, I'm going to dig in. Where should I submit my patch, if I produce one? Link to comment Share on other sites More sharing options...
Igor Posted June 14, 2015 Share Posted June 14, 2015 Where should I submit my patch, if I produce one? Most convenient way is directly on Github, but you can post here as well. It also writes to the sysfs, setting the block IO scheduler. That part is suspicious, yes. Link to comment Share on other sites More sharing options...
berturion Posted March 3, 2016 Share Posted March 3, 2016 Hello, Is it safe to completely delete this service and how to do so ? I tried "systemctl stop armhwinfo && systemctl disable armhwinfo", rebooted. But the problem is that, sometimes (I don't know why) a command like: root@xxxxx:/# service --status-all [ + ] ajenti [ - ] alsa-utils [ - ] apache2 # it stops here... waiting forever... or: root@xxxxx:/# systemctl status armhwinfo hangs indefinitely... I also have no possibility to use ssh when this error occurs. Link to comment Share on other sites More sharing options...
berturion Posted March 3, 2016 Share Posted March 3, 2016 I simply moved the /etc/init.d/armhwinfo to a backup folder. I hope this will not cause some trouble. Link to comment Share on other sites More sharing options...
Igor Posted March 3, 2016 Share Posted March 3, 2016 The file will be back with next update since it's a part of armbian This script is changing lately very much and it will change more. It's somehow important for first boot, later less. Link to comment Share on other sites More sharing options...
tkaiser Posted March 3, 2016 Share Posted March 3, 2016 I simply moved the /etc/init.d/armhwinfo to a backup folder. I hope this will not cause some trouble. Better idea might be to help us understand the behaviour on your system. Could you try it with the latest version? cd /tmp && wget -q -O - https://raw.githubusercontent.com/igorpecovnik/lib/master/scripts/armhwinfo /bin/bash ./armhwinfo start curl -F 'sprunge=<-' http://sprunge.us </var/log/armhwinfo.log The 3rd line would put the newly created armhwinfo.log on an online pastebin service and displays the URL to you. In case you want to use pastebin.com instead or curl isn't installed please put the contents of /var/log/armhwinfo.log there manually and post the link here in the forum. /var/log/armhwinfo.log should help us diagnose user problems more easily. In case the new armhwinfo doesn't spit out weird errors it would be good if you replace it, have an eye on systemd behaviour again and report back. Link to comment Share on other sites More sharing options...
berturion Posted March 4, 2016 Share Posted March 4, 2016 The url is here: http://sprunge.us/dFBB I will place this new script in /etc/init.d and report back the behavior. EDIT: For now, with new script re-enabled: $ sudo systemctl status armhwinfo â— armhwinfo.service - LSB: Armbian gathering informations about hardware Loaded: loaded (/etc/init.d/armhwinfo) Active: active (exited) since ven. 2016-03-04 09:12:41 RET; 6s ago Process: 2854 ExecStart=/etc/init.d/armhwinfo start (code=exited, status=0/SUCCESS) mars 04 09:12:30 xxxxxxxx armhwinfo[2854]: [ ok ] Setting cfg I/O scheduler for sda mars 04 09:12:30 xxxxxxxx armhwinfo[2854]: [ ok ] Setting noop I/O scheduler for mmcblk0 mars 04 09:12:31 xxxxxxxx armhwinfo[2854]: [ ok ] Starting ARM hardware info: Cubieboard mars 04 09:12:41 xxxxxxxx systemd[1]: Started LSB: Armbian gathering informations about hardware. 1 Link to comment Share on other sites More sharing options...
tkaiser Posted March 4, 2016 Share Posted March 4, 2016 Thx for the feedback. Seems to be fixed. Maybe enhancing armhwinfo while preparing the 5.03/5.04 releases led to that since I tried to optimise the code too optimistically. Now we have a more conservative behaviour when called differently and that seems to be the culprit. Please test a bit more also with service and systemd-analyze critical-chain and report back again so we can close this issue. Link to comment Share on other sites More sharing options...
berturion Posted March 4, 2016 Share Posted March 4, 2016 Thx for the feedback. Seems to be fixed. Maybe enhancing armhwinfo while preparing the 5.03/5.04 releases led to that since I tried to optimise the code too optimistically. Now we have a more conservative behaviour when called differently and that seems to be the culprit. Please test a bit more also with service and systemd-analyze critical-chain and report back again so we can close this issue. $ sudo systemd-analyze critical-chain The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. graphical.target @37.280s └─multi-user.target @37.273s └─smbd.service @34.013s +3.199s └─nmbd.service @14.457s +19.525s └─basic.target @14.224s └─timers.target @14.187s └─systemd-tmpfiles-clean.timer @14.187s └─sysinit.target @14.185s └─nfs-common.service @13.679s +504ms └─rpcbind.target @13.643s └─rpcbind.service @13.443s +198ms └─network-online.target @13.406s └─network.target @13.406s └─networking.service @5.551s +7.852s └─local-fs.target @5.490s └─proc-fs-nfsd.mount @15.904s └─local-fs-pre.target @2.227s └─systemd-remount-fs.service @2.006s +125ms └─keyboard-setup.service @1.159s +805ms └─systemd-udevd.service @1.093s +25ms └─systemd-tmpfiles-setup-dev.service @853ms +98ms └─kmod-static-nodes.service @725ms +60ms └─system.slice @645ms └─-.slice @641ms $ sudo service --status-all [ + ] ajenti [ - ] alsa-utils [ - ] apache2 [ - ] armhwinfo [ - ] bluetooth [ - ] bootlogs [ - ] bootmisc.sh [ - ] brcm40183-patch [ - ] checkfs.sh [ - ] checkroot-bootclean.sh [ - ] checkroot.sh [ + ] console-setup [ + ] cpufrequtils [ + ] cron [ + ] dbus [ + ] fake-hwclock [ - ] firstrun [ + ] haveged [ + ] hddtemp [ + ] hdparm [ - ] hostapd [ - ] hostname.sh [ - ] hwclock.sh [ + ] inadyn [ + ] kbd [ + ] keyboard-setup [ - ] keymap.sh [ - ] killprocs [ + ] kmod [ + ] lirc [ + ] loadcpufreq [ + ] memcached [ + ] minidlna [ - ] motd [ - ] mountall-bootclean.sh [ - ] mountall.sh [ - ] mountdevsubfs.sh [ - ] mountkernfs.sh [ - ] mountnfs-bootclean.sh [ - ] mountnfs.sh [ + ] mysql [ + ] networking [ + ] nfs-common [ + ] nfs-kernel-server [ + ] nginx [ + ] nmbd [ + ] ntp [ + ] php5-fpm [ + ] procps [ + ] prosody [ + ] rc.local [ - ] resize2fs [ - ] rmnologin [ + ] rpcbind [ - ] rsync [ + ] rsyslog [ + ] samba [ + ] samba-ad-dc [ - ] screen-cleanup [ - ] sendsigs [ + ] smbd [ - ] sudo [ + ] sysfsutils [ ? ] thin [ + ] udev [ + ] udev-finish [ - ] umountfs [ - ] umountnfs.sh [ - ] umountroot [ - ] unattended-upgrades [ + ] urandom [ - ] vdr [ + ] winbind [ - ] x11-common For me, all is good now. Thanks for this update Link to comment Share on other sites More sharing options...
Recommended Posts