Again, maybe I just need some more context to understand the reasoning behind this change.

Reword comment to say the namespace instead of just namespace.

Update to avoid rebase conflicts.

Update to avoid rebase conflicts.

Create a new cap_filed structure and accompanying cfiled SLIST for filed integrity verification in libcasper's cap_p_open().

Create filed nvlist directly from readconfigfile() and address Mark's comments.

Add comment explaining intentional namespace pollution.

This patch has been applied to src under commit af93fea710385b2b11f0cabd377e7ed6f3d97c34.

This patch was getting long, as @bsdimp pointed out. Split it into three separate patches. This patch will still define the locking regime.

Include <sys/time.h> instead of <sys/timespec.h>. This causes intentional namespace pollution that mimics Linux.

• Remove locking around knlist_add() and set islocked arg to 0
• Add space under declarations in timerfd_getboottime()

• Do not initialize tfd_lock with MTX_RECURSE.
• Add assertion in filt_timerfdread(), showing that the tfd_lock is held.
• Place tfd_count in kn->kn_data.

In D41600#948035, @kib wrote:

Recursive locks is much harder to reason about and correctly use. In this case there is no sense in making the lock recursive, at worst you should add assertions instead of acquiring it more than needed.

• Add recursion to tfd_lock mtx.
• Return boolean in filt_timerfdread().
• Don't check if tfd == NULL.
• Declare struct thread in timerfd.h instead of including sys/proc.h.

Add assertions to guarantee that the iovec count returned by nvlist_get_nvlist_array() is less or equal to than TTYMSG_IOV_MAX, the maximum amount of iovecs allowed by ttymsg().

Fix minor mistyping in populate_config(). filed_count should be declared as size_t, not uint64_t.

Fix incorrect handling of the nvlist size argument for in nvlist_get_nvlist_array() and nvlist_get_binary()

Address @grahamperrin's comments.

Don't manually add the iovec count to the nvlist. The iovec count is fetched when getting the nvlist iovec array.

Don't manually add the filed count to the nvlist. The filed count is fetched when getting the nvlist filed array.

• Address Mark's style(9) comments
• Add error checking for strdup() in prop_filter_compile()

In D38459#947334, @imp wrote:

Are there any tests?

Open the renamed syslogd.casper service (used to be syslogd.*).

Address Mark's comments

Add XXX comment for needed future tzcode capability module

• Do not allocate a new iovlist in nvlist_to_iovec()
• Use calloc() when allocating memory for the iovlist array.

• Change service name to syslogd.casper
• Compile the regex exp in nvlist_to_prop_filter()

• Do not add sockets with sl_recv == NULL to the kqueue.
• Remove listen() altogether.

In D41403#947165, @markj wrote:

Do you have any updates to this patch? I think I will commit it first, since I'm still waiting for the stable/14 branch, but having extra tests poses no problems.

I believe that you could leave the block which calls listen() alone (and I do think that block is totally bogus and could be deleted, syslogd doesn't handle listening sockets) and the problem would still be gone. Is that right?

In D41526#947145, @markj wrote:

In D41526#947144, @jfree wrote:

In D41526#947143, @markj wrote:

I don't really understand this change. You wrote, "To fix this, listen() should not be called if syslogd is in secure mode.", but nothing has changed with respect to listen() calls. All that's changed is that we don't call shutdown().

If the problem is that data on unread sockets is thrashing kevent(), why not avoid creating EVFILT_READ events for those sockets?

Notice the else on line 3751. If we're in secure mode and we have INET sockets, then sl_recv will be set to NULL, else we will listen. No listening happens in secure mode for INET sockets.

Now I'm even more confused. :) hints.ai_socktype = SOCK_DGRAM in the sole caller of socksetup(), so when is it the case that ai->ai_socktype != SOCK_DGRAM?

In D41526#947143, @markj wrote:

I don't really understand this change. You wrote, "To fix this, listen() should not be called if syslogd is in secure mode.", but nothing has changed with respect to listen() calls. All that's changed is that we don't call shutdown().

If the problem is that data on unread sockets is thrashing kevent(), why not avoid creating EVFILT_READ events for those sockets?

Use cap_xfer_nvlist() to transfer nvlists in cap_wallmsg(). Previously, cap_send_nvlist() was used without cap_recv_nvliust(), leaving an extra nvlist on libcasper's queue. This resulted in future nvlist transfers to retreive the wrong result.

Update to avoid rebase conflicts

Make sure that filed->f_type is F_FILE before adding descriptor to nvlist

Close console/tty descriptors while config parsing.

Use cap_ttymsg() instead of ttymsgat()

Add cap_ttymsg() and update to avoid rebasing conflicts

Use logerror() to log errors instead of exiting. This makes debugging significantly easier when something goes wrong during configuration parsing.

In prop_filter_compile(), the filter string pointer is modified so free()'ing it leads to unintended behavior. Save a filter_begpos pointer and free() that during cleanup.

Update diff to include context

Call die() instead of err() in waitdaemon when an error occurs so the pidfile is removed.

Update after peerlist rebase, adding pidfile_remove()

Update after peerlist rebase, adding pidfile_remove() in cleanup

Bring back peerlist -- see updated patch summary

Update after rebase conflicts

Fix conflicts after rebase. The previous revision has been squashed into a patch earlier in the stack.

Update after rebase conflicts

Fix bug where syslogd would stall upon startup, never getting the chance to fsync().

Remove ts and tsp variables altogether (see updated patch summary)

In D41363#945268, @slw_zxy.spb.ru wrote:

In D41363#945202, @jfree wrote:

In D41363#944911, @slw_zxy.spb.ru wrote:

I am use syslogd for collectiong messages from many sourcses.
I have moderate message flow (about 1..10 messages/second average).
I am applay D41357, D41358, D41359, D41360, D41362 -- no problems.
I am applay D41363 -- after about 1..5 minutes syslogd stop to got and processing remote messages. Local messages still processing.
Most of remote messages don't recived and lost -- no action in kevent().
After D41363 syslogd is broken.

I was able to reproduce this issue and it seems Mark was right, removing EV_CLEAR from kevent() flags, fixes the messages stalling.

Oddly enough, this bug doesn't occur when the messages are sent through syslogd's UDP socket locally. This only happens when the messages are coming from another host.

@slw_zxy.spb.ru, would you mind seeing if this new patch works for you?

Yes, now work for me.

Remove EV_CLEAR flag when adding logsocket kevents to kqueue so we don't drop INET messages.

In D41363#944911, @slw_zxy.spb.ru wrote:

I am use syslogd for collectiong messages from many sourcses.
I have moderate message flow (about 1..10 messages/second average).
I am applay D41357, D41358, D41359, D41360, D41362 -- no problems.
I am applay D41363 -- after about 1..5 minutes syslogd stop to got and processing remote messages. Local messages still processing.
Most of remote messages don't recived and lost -- no action in kevent().
After D41363 syslogd is broken.

Remove reload parameter in close_filed(). Move kqueue deletion into closelogfiles() instead.

Add boolean reload parameter to close_filed(). When set to true, remove kevents that reference the filed.

Launch syslogd with the -d debug flag to provide more diagnostic information upon test failures.

The nulldesc descriptor is used in waitdaemon() so open it prior to calling waitdaemon()

Move consfile setup before waitdaemon() to align with nulldesc ordering in https://reviews.freebsd.org/D41381

Do not assign boolean value to integer mask_C1