Trying to install a package on my target that does a useradd/groupadd fails. # opkg install cronie Installing cronie (1.5.0-r0.5) on root. Downloading http://192.168.1.15/teton-p0382-feeds/cortexa9hf-neon/cronie_1.5.0-r0.5_cortexa9hf-neon.ipk. Removing any system startup links for crond ... Running groupadd commands... NOTE: cronie: Performing groupadd with [ --system crontab] flock: invalid option -- 'w' BusyBox v1.24.1 (2016-03-29 10:44:00 CEST) multi-call binary. Usage: flock [-sxun] FD|{FILE [-c] PROG ARGS} ERROR: cronie: groupadd command did not succeed. To remove package debris, try `opkg remove cronie`. To re-attempt the install, try `opkg install cronie`. Collected errors: * pkg_run_script: package "cronie" preinst script returned status 1. * preinst_configure: Aborting installation of cronie. * opkg_install: Cannot install package cronie. Built on 2016-03-31 using Poky/Yocto 21823cb466e79540567ad1a43ae6f93d850e4057 # opkg search /usr/sbin/groupadd* shadow - 4.2.1-r0.7 Note: there is no problem building an image from scratch that includes 'cronie', only when it is being installed on the target for the first time.
CCing Kai: this seems to be the guilty commit: commit 57a525ca7271a8fe3913c61aa87cb0ba1674b4b2 Author: Kai Kang <kai.kang@windriver.com> Date: Mon Feb 29 17:19:32 2016 +0800 useradd_base.bbclass: replace retry logic with flock When perform useradd during populate sysroot, it locks files passwd.lock and group.lock at same time. And then it meets a dead lock issue randomly. Use flock to reslove it by using an universal lock directory for all the user and group related operations. [YOCTO #9022] (From OE-Core rev: 2ebf697b46c42cee8bfa6d2e6087397f8cce385c) busybox flock does not support "-w".
One option would be to remove the -w, as that just sets a timeout on the lock. useradd or pseudo are unlikely to hang forever so the locks will be short-lived.
(In reply to comment #2) > One option would be to remove the -w, as that just sets a timeout on the > lock. useradd or pseudo are unlikely to hang forever so the locks will be > short-lived. OK. I'll do some tests with removing option '-w' and send a pull request.
(In reply to comment #2) > One option would be to remove the -w, as that just sets a timeout on the > lock. useradd or pseudo are unlikely to hang forever so the locks will be > short-lived. Before the patch I linked to the code used to have a retry-loop instead. So removing -w now means we remove race-avoidance code that someone added (presumably for a reason)... This seems to be the original commit for the retry-loop (that was then replaced with "flock -w"): commit c9537c52f4a7faef9aa2d23b33bc452aa872068d Author: Scott Garman <scott.a.garman@intel.com> Date: Thu Mar 22 21:43:42 2012 -0700 useradd.bbclass: retry useradd/groupadd commands to avoid lock race issues A race condition can occur when adding users and groups to the passwd and group files, causing errors like the following: ERROR: Function 'useradd_sysroot' failed Tried to access "/etc/group" but this was locked. This fix will cause the useradd code to retry the useradd and groupadd commands up to 10 times (with a 1s sleep in between attempts) before failing. This fixes [YOCTO #1794] (From OE-Core rev: 68c589f1b5ee36f0aff151b728447ffdae14622c) Signed-off-by: Scott Garman <scott.a.garman@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The old code basically said "try to add a user and if it fails then wait a bit and try again, ten times". We wrapped the logic with our own locks so we can wait instead of failing, as flock waits by default. -w simply adds a timeout to the wait, and this isn't part of busybox flock.
Fixed in oe-core 5cf97364685bfb86c6eeaffcebcad62ba9f93ee4.