On 04/08/2012 10:00 PM, Scott Garman wrote:
On 04/07/2012 04:59 PM, Saul Wold wrote:
On 04/05/2012 11:53 PM, Scott Garman wrote:
Hello,
This pull request includes a patch to shadow to disable logging to
syslog, to prevent sysroot user and group additions from writing
entries to the host's syslog.
I have build-tested this with core-image-sato (which builds a few
useradd-based recipes, such as avahi and dbus) for all 5 of our
qemu architectures, while watching my syslog to verify that no
useradd or groupadd entries were written.
With this patch applied, the following error was seen on the AB:
| Running useradd commands...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| WARNING: useradd command did not succeed. Retrying...
| ERROR: tried running useradd command 10 times without success,
giving up
Check the AB here:
http://autobuilder.yoctoproject.org:8010/builders/nightly-arm/builds/369/steps/shell_19/logs/stdio
Hi Saul,
The syslog disable patch cannot trigger this error, I'm pretty certain
you have encountered another problem.
The useradd class now uses code which checks that the user account or
group account was created in the passwd and group files, respectively.
If the account was not created (which is verified via a grep command),
the script sleeps for 1 second and tries again, up to 10 times. This is
intended to avoid lockfile races, as useradd and groupadd lock the
passwd and group files when creating accounts.
It seems extremely unlikely that the passwd file was locked for a full
10s worth of attempts to access it. I also see from the logs that the
base-passwd package was installed before this error was encountered,
which *should* rule out the possibility that the useradd command was
failing because /etc/passwd didn't exist yet.
Later useradd commands are also failing in this manner, which makes me
suspect that something is wrong with the /etc/passwd file in this image.
The groupadd commands, on the other hand, are succeeding without any
retries.
So it would be helpful for me to know answers to the following:
Was this a build from scratch or from sstate?
This was from sstate.
Is this problem reproducible? (I'm starting a build from scratch
overnight on my end)
Only saw it on one build over the weekend, but turns out a bug already
existed with this issue, but it was filed as a PAM build failure (see
2218) , which maybe I need to re-assign to you.
What does the etc/passwd file in this image look like?
You can get it from the AB yourself, correct? If not, let me know please.
Sau!
Thanks,
Scott
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
