[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Updating mumi on berlin
From: |
Ludovic Courtès |
Subject: |
Re: Updating mumi on berlin |
Date: |
Sun, 15 May 2022 22:59:36 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hi,
Thiago Jung Bauermann <bauermann@kolabnow.com> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi,
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>
>>> Yes, that would be the correct and general solution (I hope you get to
>>> fix it, else I may look into it in some time). Workarounds currently in
>>> use can be seen in our mutter package definition (it's a bit convoluted,
>>> having to fork a process in which we set the child reaping property and
>>> invoke the test suite via tini, acting as a fake PID 1).
>>
>> The Guile process running the build script (with the build phases) runs
>> as PID 1. So how about doing one of these:
>>
>> 1. Add a final phase that does (waitpid WAIT_ANY).
>>
>> 2. Add a SIGCHLD handler that calls ‘waitpid’.
>>
>> I suspect the former is enough.
>
> I don't think it is, unless I'm misunderstanding something. The
> testsuite expects the daemon to die within a few seconds of sending it
> the quit command (which it does several times over the course of a
> number of the tests), so having it reaped at the end of the build
> process won't help.
I see, makes sense.
> I tried the latter a couple of weeks ago and it didn't work either,
> though it's highly likely that I did something wrong in my Scheme code.
> I also didn't use the 1-second timer hack so perhaps that was it.
>
> I just tested this (adapted from the mutter package) and it worked:
>
> @@ -4137,6 +4142,26 @@ (define-public public-inbox
> ;; the builder.
> (substitute* "t/httpd-unix.t"
> (("^SKIP: \\{") "SKIP: { skip('Guix');"))))
> + (replace 'check
> + (lambda* (#:key target
> + (tests? (not target)) (test-flags '())
> + #:allow-other-keys)
> + (if tests?
> + (match (primitive-fork)
> + (0 ;child process
> + (set-child-subreaper!)
> + ;; Use tini so that signals are properly handled and
> + ;; doubly-forked processes get reaped; otherwise,
> + ;; lei-daemon is kept as a zombie and the testsuite
> + ;; fails thinking that it didn't quit as it should.
> + (apply execlp "tini" "--"
> + "make" "check" test-flags))
How does a basic SIGCHLD handler fare?
(sigaction SIGCHLD
(lambda _ (false-if-exception (waitpid WAIT_ANY WNOHANG))))
>> Eventually, we should do one of these in gnu-build-system.scm, as in:
>>
>> https://issues.guix.gnu.org/30948#2
>>
>> WDYT?
>
> I agree, possibly with the 1-second timer hack as well.
Heh, I hate that one, we need to find a better solution.
Thanks,
Ludo’.
- Re: Updating mumi on berlin, zimoun, 2022/05/02
- Re: Updating mumi on berlin, Arun Isaac, 2022/05/03
- Re: Updating mumi on berlin, Thiago Jung Bauermann, 2022/05/03
- Re: Updating mumi on berlin, zimoun, 2022/05/04
- Re: Updating mumi on berlin, Kyle Meyer, 2022/05/04
- Re: Updating mumi on berlin, Thiago Jung Bauermann, 2022/05/04
- Re: Updating mumi on berlin, Maxim Cournoyer, 2022/05/05
- Re: Updating mumi on berlin, Thiago Jung Bauermann, 2022/05/05
- Re: Updating mumi on berlin, Ludovic Courtès, 2022/05/07
- Re: Updating mumi on berlin, Thiago Jung Bauermann, 2022/05/07
- Re: Updating mumi on berlin,
Ludovic Courtès <=
- Re: Updating mumi on berlin, Maxime Devos, 2022/05/16
- Re: Updating mumi on berlin, zimoun, 2022/05/05
- public-inbox v1.7 update (was: Updating mumi on berlin), Kyle Meyer, 2022/05/05
- Re: public-inbox v1.7 update (was: Updating mumi on berlin), zimoun, 2022/05/06
- Re: public-inbox v1.7 update (was: Updating mumi on berlin), Kyle Meyer, 2022/05/08
- Re: public-inbox v1.7 update (was: Updating mumi on berlin), zimoun, 2022/05/09
- Re: Updating mumi on berlin, Thiago Jung Bauermann, 2022/05/06
- Re: Updating mumi on berlin, zimoun, 2022/05/06
- Re: Updating mumi on berlin, Thiago Jung Bauermann, 2022/05/15