Page MenuHomeFreeBSD

daemon: stop rebuilding the kqueue every restart of the child
ClosedPublic

Authored by kevans on Oct 8 2024, 5:23 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Jan 5, 9:49 PM
Unknown Object (File)
Sat, Dec 28, 9:40 AM
Unknown Object (File)
Fri, Dec 27, 12:18 PM
Unknown Object (File)
Fri, Dec 27, 9:40 AM
Unknown Object (File)
Fri, Dec 27, 8:18 AM
Unknown Object (File)
Fri, Dec 27, 6:00 AM
Unknown Object (File)
Dec 15 2024, 7:04 PM
Unknown Object (File)
Dec 13 2024, 9:22 AM
Subscribers

Details

Summary

We populate the kqueue with all of four kevents: three signal handlers and
one for read of the child pipe. Every time we start the child, we rebuild
this kqueue from scratch for the child and tear it down before we exit and
check if we need to restart the child. As a consequence, we effectively
drop any of the signals we're interested in between restarts.

Push the kqueue out into the daemon state to avoid losing any signal events
in the process, and reimplement the restart timer in terms of kqueue timers.
The pipe read event will be automatically deleted upon last close, which
leaves us with only the signal events that really get retained between
restarts of the child.

PR: 277959

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 59856
Build 56741: arc lint + arc unit

Event Timeline

markj added inline comments.
usr.sbin/daemon/daemon.c
538

After this change, it's not safe to use daemon_sleep() in code paths where there are still any other event types on the queue. That's fine today, but it might cause problems later. I'd at least add a comment explaining this.

This revision is now accepted and ready to land.Oct 8 2024, 12:10 PM

Add some comments about daemon_sleep() expectations, and what to look for if we
hit the assertion in the middle about other filter types being raised.

Also add in a couple more assertions about the pipe being closed to hit early if
that specific bit wasn't cleaned up from the eventloop.

This revision now requires review to proceed.Oct 9 2024, 1:05 AM
This revision is now accepted and ready to land.Oct 9 2024, 9:00 AM