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?

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.

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?

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.

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.

I simply moved the /etc/init.d/armhwinfo to a backup folder. I hope this will not cause some trouble.

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.

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.

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.

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.

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