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

[Scott Garman]

On 04/09/2012 08:30 AM, Saul Wold wrote:
> 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.

Yes, I've re-assigned this bug to myself.

>> 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.

This was a nightly build and it no longer appears to be on the server - 
assuming I'm connected to the correct one?

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center