imapd.t failing on OpenBSD, bisects to 13a2088c74fd (kqnotify: drop EV_CLEAR (edge triggering))

["Štěpán Němec" <stepnem@smrk.net>]

(Bisected with HEAD at 042662948d804d24 (bad) and good at
62d50411dcc92cd (hadn't updated/run the tests for a few weeks.))

It's a bit of a mess, though, it doesn't fail completely
reliably and not always quite the same way.  Here's a log
of a few examples:

http://smrk.net/tmp/imapd.t.failures

Reverting 13a2088c74fd (readding EV_CLEAR) I got 12 passing
imapd.t runs in a row (as well as a full passing `make test`
run), removing EV_CLEAR again I got 3 passes, 1 fail, and in
the 5th run it just hung (another time it managed to
complete 10 imapd.t runs with just 2 fails and no hang).

It also leaves behind funny processes like this:

ooo# ps -f -U pi
  PID TT  STAT        TIME COMMAND
60002 p1  I+p      0:00.05 sh
69047 p1  R/1     20:06.56 perl: -watch quitting quitting (perl)
27951 p1  R/1     33:06.54 - perl:  (perl)
 5020 p1  I        0:00.09 `-- /usr/local/bin/git --git-dir=watchimap/all.git -c core.abbrev=no
83900 p1  R/0     14:18.88 perl: -watch quitting quitting (perl)
85123 p1  R/0     27:28.68 - perl: UID:4 inbox.i1.0 imap://[::1]:21825 quitting quitting quitting quitting quitting quitting quitting quitting quitting quitting quitting qui
78162 p1  I        0:00.17 `-- /usr/local/bin/git --git-dir=watchimap/all.git -c core.abbrev=no

which, given the hangs, makes me wonder if it's bumping into
some kind of resource limit?

(These tests were run on an OpenBSD development snapshot,
not a release, but given that reverting the change makes the
problem disappear I hope that doesn't matter.)

-- 
Štěpán