Re: [PATCH 0/1] shadow-native: disable logging to syslog

[Saul Wold <sgw@linux.intel.com>]

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
>