[Varnish] #1841: r01801.vtc panic on OSX: vwk_thread(), waiter/cache_waiter_kqueue.c line 109:

[Varnish]

#1841: r01801.vtc panic on OSX: vwk_thread(), waiter/cache_waiter_kqueue.c line
109:
----------------------+----------------------------------------
 Reporter:  lkarsten  |       Owner:  Poul-Henning Kamp <phk@…>
     Type:  defect    |      Status:  closed
 Priority:  normal    |   Milestone:
Component:  varnishd  |     Version:  trunk
 Severity:  normal    |  Resolution:  fixed
 Keywords:            |
----------------------+----------------------------------------
Changes (by Poul-Henning Kamp <phk@…>):

 * status:  new => closed
 * owner:   => Poul-Henning Kamp <phk@…>
 * resolution:   => fixed


Comment:

 In [0311c78353cbacbec73a155807d3777749dd0802]:
 {{{
 #!CommitTicketReference repository=""
 revision="0311c78353cbacbec73a155807d3777749dd0802"
 Replace alien FD's with /dev/null rather than just closing them

 When we fork the worker process, we close all filedescriptors we
 have not explictly marked for it to inherit, for security reasons.

 Operating system libraries may have open filedescriptors (see
 end*ent(3)) and there is no way to chase these down.

 At least on OSX something related to DNS lookups leaves such
 a FD around, and when that code later discovers the FD doesn't
 work, it closes it, even though it no longer owns it.

 In ticket 1841, that happens to be FD7 which is one of our kqueue FDs.

 Normally such library code should set 'close-on-exec' status with
 fcntl(2) but that doesn't seem to be the case here, and this bit
 of wisdom seems neglegted about 50/50, so it probably wouldn't
 help us to examine this.

 The fix here is to close the FDs, and replace them with a FD open
 to /dev/null, so that there is no risk of information leak, but we
 don't reuse the FD for something else until the library has properly
 closed it.

 Fixes #1841
 }}}

-- 
Ticket URL: <https://www.varnish-cache.org/trac/ticket/1841#comment:1>
Varnish <https://varnish-cache.org/>
The Varnish HTTP Accelerator