GNU bug report logs -
#41507
[PATCH Shepherd 0/2] Use 'signalfd' on GNU/Linux
Previous Next
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Sun, 24 May 2020 14:28:01 UTC
Severity: normal
Tags: patch
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Wed, 27 May 2020 00:13:53 +0200
with message-id <875zcimjj2.fsf <at> gnu.org>
and subject line Re: [bug#41507] [PATCH Shepherd 2/2] shepherd: Use 'signalfd' when possible.
has caused the debbugs.gnu.org bug report #41507,
regarding [PATCH Shepherd 0/2] Use 'signalfd' on GNU/Linux
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
41507: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=41507
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Hello!
This patch series allows shepherd to use ‘signalfd’ on GNU/Linux.
It allows us to avoid race conditions related to signal delivery,
which in turn means we can pass an infinite timeout to ‘select’,
and thus increase battery life.
More generally, it’s a way to structure the code around the event
loop. The next step will be to make the code entirely reactive,
so we can have things like socket activation, being able to start
services that don’t depend on one another concurrently, and all that.
(This is actually also be possible without ‘signalfd’ but it’s more
consistent and robust to have everything visible to ‘select’.)
Thoughts?
I guess the main question is: can it go into 0.8.1, which we outta
release soon due to <https://issues.guix.gnu.org/40981>. I’d say
“yes”, but I’ll be even more confident if others take a look. :-)
Ludo’.
Ludovic Courtès (2):
system: Add support for 'signalfd'.
shepherd: Use 'signalfd' when possible.
configure.ac | 18 +++++++++
modules/shepherd.scm | 73 ++++++++++++++++++++++++++++++----
modules/shepherd/service.scm | 19 +++++----
modules/shepherd/system.scm.in | 65 ++++++++++++++++++++++++++++++
4 files changed, 161 insertions(+), 14 deletions(-)
--
2.26.2
[Message part 3 (message/rfc822, inline)]
Hi!
Mathieu Othacehe <othacehe <at> gnu.org> skribis:
>> + (lambda args
>> + (if (= ENOSYS (system-error-errno args))
>> + #f
>> + (apply throw args)))))
>
> Maybe:
>
> (and (= ENOSYS (system-error-errno args))
> (apply throw args))
It’s not equivalent. :-)
>> +(define (handle-signal-port port)
>> + "Read from PORT, a signalfd port, and handle the signal accordingly."
>> + (let ((signal (consume-signalfd-siginfo port)))
>> + (cond ((= signal SIGCHLD)
>> + (handle-SIGCHLD))
>> + ((= signal SIGINT)
>> + (catch 'quit
>> + (lambda ()
>> + (stop root-service))
>> + quit-exception-handler))
>
> Maybe we should create a handle-SIGINT, to make sure that the same code
> is shared with the sigaction handler?
Good idea, done!
>> + (begin
>> + ;; Unblock any signals that might have been blocked by the parent
>> + ;; process.
>> + (unblock-signals (list SIGCHLD SIGINT SIGHUP SIGTERM))
>
> This made me realize that we may want to disable/reset SIGINT and
> SIGHUP, in the same way that we do for SIGTERM? This is not related to
> your patch anyway.
Right, I’ll let you look into it if that’s fine with you.
> You could also extend the comment to say that it is only necessary if
> using the signalfd mechanism (because signals are not blocked
> otherwise).
Done.
I did:
make dist
guix build shepherd --with-source=shepherd-0.8.0.tar.gz \
-s x86_64-linux -s i686-linux -s armhf-linux -s aarch64-linux
guix build shepherd --with-source=shepherd-0.8.0.tar.gz \
--target=i586-pc-gnu
and it all passes.
Janneke, could you check that it works on GNU/Hurd?
Ludo’.
This bug report was last modified 4 years and 350 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.