<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugzilla.yoctoproject.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.6"
          urlbase="https://bugzilla.yoctoproject.org/"
          
          maintainer="it-coreprojects-helpdesk@linuxfoundation.org"
>

    <bug>
          <bug_id>9371</bug_id>
          
          <creation_ts>2016-04-01 05:23:16 +0000</creation_ts>
          <short_desc>user/group add doesn&apos;t work on target</short_desc>
          <delta_ts>2016-04-14 13:55:42 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>7</classification_id>
          <classification>Build System, Metadata &amp; Runtime</classification>
          <product>OE-Core</product>
          <component>core</component>
          <version>2.1</version>
          <rep_platform>x86</rep_platform>
          <op_sys>Multiple</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>Medium+</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>2.1 M4</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Gary Thomas">gary</reporter>
          <assigned_to name="Ross Burton">ross.burton</assigned_to>
          <cc>jku</cc>
    
    <cc>kai.kang</cc>
    
    <cc>meta.mr.watcher</cc>
    
    <cc>meta.watcher</cc>
          
          
          <cf_os>---</cf_os>
          <cf_regression_type>Regression (Used to work)</cf_regression_type>
          
          <cf_docchange>No (bug/feature does not impact docs)</cf_docchange>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>60649</commentid>
    <comment_count>0</comment_count>
    <who name="Gary Thomas">gary</who>
    <bug_when>2016-04-01 05:23:16 +0000</bug_when>
    <thetext>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 -- &apos;w&apos;
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 &quot;cronie&quot; 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 &apos;cronie&apos;, only when it is being installed on the target for the first time.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>60899</commentid>
    <comment_count>1</comment_count>
    <who name="Jussi Kukkonen">jku</who>
    <bug_when>2016-04-07 12:10:11 +0000</bug_when>
    <thetext>CCing Kai: this seems to be the guilty commit:

commit 57a525ca7271a8fe3913c61aa87cb0ba1674b4b2
Author: Kai Kang &lt;kai.kang@windriver.com&gt;
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 &quot;-w&quot;.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>60901</commentid>
    <comment_count>2</comment_count>
    <who name="Ross Burton">ross.burton</who>
    <bug_when>2016-04-07 13:09:01 +0000</bug_when>
    <thetext>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.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>60956</commentid>
    <comment_count>3</comment_count>
    <who name="Kai Kang">kai.kang</who>
    <bug_when>2016-04-08 02:36:40 +0000</bug_when>
    <thetext>(In reply to comment #2)
&gt; One option would be to remove the -w, as that just sets a timeout on the
&gt; lock.  useradd or pseudo are unlikely to hang forever so the locks will be
&gt; short-lived.

OK. I&apos;ll do some tests with removing option &apos;-w&apos; and send a pull request.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>60962</commentid>
    <comment_count>4</comment_count>
    <who name="Jussi Kukkonen">jku</who>
    <bug_when>2016-04-08 07:06:34 +0000</bug_when>
    <thetext>(In reply to comment #2)
&gt; One option would be to remove the -w, as that just sets a timeout on the
&gt; lock.  useradd or pseudo are unlikely to hang forever so the locks will be
&gt; 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 &quot;flock -w&quot;):

commit c9537c52f4a7faef9aa2d23b33bc452aa872068d
Author: Scott Garman &lt;scott.a.garman@intel.com&gt;
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 &apos;useradd_sysroot&apos; failed
     Tried to access &quot;/etc/group&quot; 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 &lt;scott.a.garman@intel.com&gt;
    Signed-off-by: Richard Purdie &lt;richard.purdie@linuxfoundation.org&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>61041</commentid>
    <comment_count>5</comment_count>
    <who name="Ross Burton">ross.burton</who>
    <bug_when>2016-04-11 20:49:21 +0000</bug_when>
    <thetext>The old code basically said &quot;try to add a user and if it fails then wait a bit and try again, ten times&quot;.

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&apos;t part of busybox flock.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>61207</commentid>
    <comment_count>6</comment_count>
    <who name="Ross Burton">ross.burton</who>
    <bug_when>2016-04-14 13:55:42 +0000</bug_when>
    <thetext>Fixed in oe-core 5cf97364685bfb86c6eeaffcebcad62ba9f93ee4.</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>