bug#33362: System tests stuck in "shepherd[1]: waiting for udevd..."

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Wed, 05 Jan 2022 at 00:21, zimoun <zimon.toutoune@gmail.com> wrote:
> On Fri, 26 Nov 2021 at 18:21, Mark H Weaver <mhw@netris.org> wrote:
>>> On Mon, 12 Nov 2018 at 20:09, Mark H Weaver <mhw@netris.org> wrote:
>>>
>>>> As I write this, there are two system test builds that have been stuck
>>>> for many hours, endlessly printing "shepherd[1]: waiting for udevd...":
>>>>
>>>>   https://hydra.gnu.org/build/3153725
>>>>   https://hydra.gnu.org/build/3154365
>>>>
>>>> They are both on i686-linux, and on the 'core-updates' branch, but with
>>>> two different build slaves (hydra.gnunet.org and guix.sjd.se).
>>>>
>>>> I will now abort these builds, to free up build slots for other jobs.
>>>
>>> I am doing bug triage and I hit this old one #33362 [1] from 2018.  It
>>> is about hydra which is down now, IIRC.
>>
>> I doubt that this bug was about Hydra.  It guess that the bug was in our
>> system test derivations.  As far as I know, the only relevance of Hydra
>> to this bug is that Hydra was our CI system at that time, and therefore
>> it was Hydra that brought this bug to my attention.
>
> I agree, but I am not able to connect to the mentioned logs.  Are the
> links still working?
>
>
>>> Does it still make sense to keep it open?  Or can we close it?
>>
>> If the bug hasn't occurred recently, then I agree it's okay to close it.
>>
>> It would be good to check our modern Cuirass-based ci.guix.gnu.org to
>> find out whether this failure mode is still occurring in our system
>> tests.
>>
>> I see that Cuirass's web interface has improved quite significantly in
>> the last couple of years, and I'm very grateful to those who've worked
>> on it.  However, Cuirass still seems to be missing some important
>> functionality that Hydra had.  Most notably, unless I missed something,
>> it seems to lack the ability to compare the results of two evaluations
>> and show the *differences* between those results, i.e. to enumerate the
>> newly failing jobs, the newly succeeding jobs, and the newly aborted
>> jobs.
>>
>> Without that functionality, it's not easy for us to notice when a job
>> starts to fail, unless a user files a bug report.  The total list of job
>> failures has always been too large to easily notice changes in that list
>> without assistance.
>
> I agree.  Maybe Mathieu could comment more because this missing feature
> is floating around. :-)

Since the initial report does not seem to have occurred recently and
because the feature is not related (or let open another report), I am
closing.

Feel free to reopen if I miss an important point.


Cheers,
simon