default logging output

Andrew Bartlett abartlet at
Thu Jul 7 18:43:53 MDT 2011

On Wed, 2011-07-06 at 10:48 +0200, Michael Adam wrote:
> Hi Andrew,

> This does not seem to be true. Running make test, I see logs of
> this on standard output/error:
> [2011/07/06 10:35:35,  0] ../lib/util/debug.c:572(reopen_logs_internal)
>   Unable to open new log file '/data/samba/install/master/var/log.smbd': Permission denied
> I am running "make test" (from source3) as non-root and the log file
> /data/samba/install/master/var/log.smbd is the compiled-in
> location of the log file in the install path. Now I have done
> "make install" as root. So the permission is correctly denied.
> The bug is that daemons started by "make test" try to open or
> access those logs at all. "make test" should run completely
> self-contained without accessing the install path at all.

Indeed, the indication to log to stdout on the command line is meant to
override all subsequent log directives.  I'll chase this down. 

> My suspicion is that the recent debug and dynconfig changes broke
> it. (I am not able to monitor all changes in the merging area
> lately. It is just too much, so I am going to report problems
> once I stumble across.)
> What is more, why do smbd/nmbd/winbindd log to standard output (or error)
> at startup as of recently? This his horrible! Firstly it clutters
> make test output, making it mostly unreadable (for me), and secondly,
> this should not happen when starting productive daemons either.
> At least I am used to reading the debug output from the logs.

Where would you like startup errors (such as a failure to parse the
smb.conf) to go?  If we log them to the default log file, then we may
put startup logs in one file, possibly in the wrong place, and then once
smb.conf is loaded (possibly from a registry tdb), we would start
logging to a completely different place.

Part of the challenge is how do we know the 'right' place to log before
we are told?  The logging options on the command line provide further
variations on this theme. 

Andrew Bartlett

Andrew Bartlett <abartlet at>

More information about the samba-technical mailing list