[Buildroot] [PATCH] package/syslog-ng: bump version to 3.22.1

Ricardo Martincoski ricardo.martincoski at gmail.com
Mon Sep 16 02:49:20 UTC 2019


Hello,

Few more tests from my side, but no conclusion yet.

On Mon, Sep 09, 2019 at 10:46 AM, Carlos Santos wrote:

> On Mon, Sep 9, 2019 at 8:47 AM Chris Packham <judge.packham at gmail.com> wrote:
>>
>>
>>
>> On Mon, 9 Sep 2019 23:40 Carlos Santos, <unixmania at gmail.com> wrote:
>>>
>>> > > Hi Ricardo,
>>> > >
>>> > > I ran a test on a QEMU build with udev and noticed that syslog-g hangs
>>> > > on start-up. Using strace I found that it blocks on a getrandom()
>>> > > call, which seems to be make sense since the start-up order is
>>> > >
>>> > >     /etc/init.d/S01syslog-ng
>>> > >     /etc/init.d/S10udev
>>> > >     /etc/init.d/S20urandom

Thank you for your tests.

>>> >
>>> > I didn't have any particular reason for S01 other than that's what
>>> > rsyslog does. Moving it after urandom would be fine.

I tested renaming S01syslog-ng to S22syslog-ng but the issue still occurs.
[1] https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/290335678

I also run strace with the original script name [2] and after rename [3].
[2] https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/290350949
[3] https://gitlab.com/RicardoMartincoski/buildroot/-/jobs/290351179
The timeout the tests infra waits for the login prompt in those jobs is 10
minutes, then it prints '==> System does not boot' to the log file and fails.

In both cases the messages hang in a similar way:
[pid    48] 00:01:50 <... futex resumed>) = 0
[pid    48] 00:01:50 epoll_wait(3, [{EPOLLIN, {u32=160804, u64=1058090963334180}}], 9, -1) = 1
[pid    48] 00:02:29 read(19, "\1\0\0\0\0\0\0\0", 8) = 8
[pid    48] 00:02:29 clock_gettime(CLOCK_MONOTONIC, {tv_sec=149, tv_nsec=122924000}) = 0
[pid    48] 00:02:29 close(5)           = 0
[pid    48] 00:02:29 epoll_wait(3, 
Strace never prints the other parameters for the last epoll_wait call.

>>>
>>> S01 is the right place, since udevd uses syslog and starting syslog-ng
>>> later would prevent error messages from being saved in
>>> /var/logmessages.
>>>
>>> The correct solution is to configure the kernel with the random
>>> hardware support embedded, not as a module (e.g. HW_RANDOM=y ,
>>> CONFIG_VIRTIO_PCI=y  and HW_RANDOM_VIRTIO=y in
>>> board/qemu/arm-versatile/linux.config).

It should be already the case. Of course, maybe I missed something.
First the drivers were added [4] and the test run on gitlab-ci.
>From one run, the binary kernel was saved and is now used by tests that select
the builtin kernel for armv5 [5], '-device virtio-rng-pci' is also passed to
qemu when this kernel image is used.
And finally the syslog-ng test was updated to use the builtin binary kernel [6].
[4] https://github.com/buildroot/buildroot/commit/450863097f588fe85d23e83cff14a75f1740d8fa
[5] https://github.com/buildroot/buildroot/commit/7acb32dabb80cc9f0dfc48f14e9bc86b3ef5df74
[6] https://github.com/buildroot/buildroot/commit/56e38a705e62a429576635b0a26cc4d3b3e88023

>>
>>
>> Still seems odd that this dependency exhists. Maybe there is an option to disable it.
> 
> The dependency is unavoidable. RHEL 8, for instance, which is a
> distribution with a well defined set of target environments has
> CONFIG_HW_RANDOM_VIRTIO=y in the kernel config file. On the other hand
> the linux.config files provided by Buildroot are generic and can not
> match all possible configurations.

Indeed, but I used a defconfig fragment to add them for this runtime test.


I also tested changing the version of syslog-ng:
2.19.1 OK
2.20.1 OK
2.21.1 FAIL
2.23.1 FAIL
So the next bump will not fix the runtime test.

I looked the diff between syslog-ng-3.19.1 and syslog-ng-3.20.1 but I was unable
to find some obvious problem or change in behavior.


In the lack of better ideas I also tested using another libc:
| class TestSyslogNg(infra.basetest.BRTest):
|-    config = infra.basetest.BASIC_TOOLCHAIN_CONFIG + \
|+    config = \
|         """
|+        BR2_arm=y
|+        BR2_TOOLCHAIN_EXTERNAL=y
The same runtime issue occurs.


Regards,
Ricardo


More information about the buildroot mailing list