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

[Saul Wold]

On 04/09/2012 09:23 AM, Scott Garman wrote:
> 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.
>
Ok thanks.

>>> 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?
>
ab05, since this was a non-lsb build, the tmp dir you need to look at is 
non-lsbtmp, it should be there, I just checked.


> Scott
>