Nicolas Williams' source environment variables

Luke Kenneth Casson Leighton lkcl at
Thu Feb 3 04:42:13 GMT 2000

> One concern I have about including the output of executables is that this
> means an additional fork()ing and exec()ing of a program for every such
> include done--for every time smb.conf is read.  I imagine there are others
> here who have a better idea than I of how much overhead this represents, and
> perhaps you can put my mind at ease :), but at present, I would hesitate to
> use such a feature for fear of a performance hit..

on startup.

on a TCP connection (at least twice)

on NetBIOS session request

on SMBnegprot

on SMBsesssetupX (at least twice)

on SMBtconX

there may be more [triggered by incoming network traffic, that is].

there's also a stat cache which can result in a reload of smb.conf and all
other included files -- that's every single smbd process running at the
time -- all within a ten second period or so (depending on the state of
the indicidual smbd processes, but at least SMB_IDLE_LOOP_TIME seconds).

so, potentially, it's a really, really large performance hit.  we've been
sufficiently concerned about it [and the associated memory reallocation of
all the parameter strings], that we've wanted to have an "smb.conf
parameter cache" for at least three years.

the idea being that only those parameters that have *changed* get

dan [ef.], sorry for earlier comments of mine: i want to encourage ideas
not squash them, that's not my job or authority to do that.


More information about the samba-technical mailing list