signal action is restored to default in child after fork(2).
In this case there is no need to do anything with dummy SIGCHLD handler,
because after fork(2) it will be automatically reverted to SIG_IGN.
Obtained from: Wheel Systems Sp. z o.o. http://www.wheelsystems.com
MFC after: 3 days
It is possible that the parent process ignores some of them and sigtimedwait()
will never see them, eventhough they are masked.
The most common situation for this to happen is boot process where init(8)
ignores SIGHUP before starting to execute /etc/rc. This in turn caused
hastd(8) to ignore SIGHUP.
Reported by: trasz
Obtained from: Wheel Systems Sp. z o.o. http://www.wheelsystems.com
MFC after: 3 days
more useful information. Instead of:
hastd: remote address not configured for resource foo
Print the following:
No resource foo configuration for this node (acceptable node names: freefall, freefall.freebsd.org, 44333332-4c44-4e31-4a30-313920202020).
MFC after: 3 days
races - in this case a keepalive packet was send from wrong thread which
lead to connection dropping, because of corrupted packet.
Fix it by sending keepalive packets directly from the send thread.
As a bonus we now send keepalive packets only when connection is idle.
Submitted by: Mikolaj Golub <to.my.trociny@gmail.com>
MFC after: 3 days
initialize all the data. This is huge waste of time and resources if
there were no writes yet, as there is no real data to synchronize.
Optimize this by sending "virgin" argument to secondary, which gives it a hint
that synchronization is not needed.
In the common case (where noth nodes are configured at the same time) instead
of synchronizing everything, we don't synchronize at all.
MFC after: 1 week
error messages, so when we clean up after child process, we have to check if
the event socketpair is still there.
Submitted by: Mikolaj Golub <to.my.trociny@gmail.com>
MFC after: 3 days
I'm unable to reproduce the race described in comment anymore and also the
comment is incorrect - localfd represents local component from configuration
file, eg. /dev/da0 and not HAST provider.
Reported by: Mikolaj Golub <to.my.trociny@gmail.com>
MFC after: 1 week
masking it.
This fixes bogus reports about hooks running for too long and other problems
related to garbage-collecting child processes.
Reported by: Mikolaj Golub <to.my.trociny@gmail.com>
MFC after: 3 days
This way the primary process inherits signal mask from the main process,
which fixes a race where signal is delivered to the primary process before
configuring signal mask.
Reported by: Mikolaj Golub <to.my.trociny@gmail.com>
MFC after: 3 days
while the main process sends control message to the worker process, but worker
process hasn't started control thread yet, because it waits for reply from the
main process.
The fix is to start the control thread before sending any events.
Reported and fix suggested by: Mikolaj Golub <to.my.trociny@gmail.com>
MFC after: 3 days
limited to async-signal safe functions in the child process), move all hooks
execution to the main (non-threaded) process.
Do it by maintaining connection (socketpair) between child and parent
and sending events from the child to parent, so it can execute the hook.
This is step in right direction for others reasons too. For example there is
one less problem to drop privs in worker processes.
MFC after: 2 weeks
Obtained from: Wheel Systems Sp. z o.o. http://www.wheelsystems.com
