Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mosquitto-dev] Duplicated log when using upstart>=1.4 can break systems

Hash: SHA1

Hello Roger.

Thanks for the quick answer, reply was delayed because of some yule
feasting and stuff, sorry.

On 2015-12-22 16:15, Roger Light wrote:
> If you don't specify any logging then stderr will be used,
> otherwise only the destinations that you configure should be used.

I studied the source and you're right, of course.
The reason for the generated stdio output was found elsewhere; a
"log_dest stdout" had sneaked into a file loaded from "include_dir". And
a "log_type debug" also didn't help much on the amount being logged.
Sorry for the fuss.

Nevertheless I still think this non-deliberate "side channel" logging
through stdio and upstart is strange and counterintuitive. Would
anybody ever want to use that mechanism instead of a proper configured
"log_dest file"?

I'm also still a bit puzzled about the current --daemon option. It forks
but doesn't detach stdout/err from the console so if "log_dest
stderr/stdout" is specified the console where invocation happened
receives log output. That seems a bit broken. The following howto
recommends things to do on daemonization including detaching and some
other details;

I would suggest that when spawned from upstart in the function as a
daemon (maybe even using --daemon?) mosquitto should detach stdout/err
and leave logging to only what is mandated by configuration. Or at least
only output messages critical to the operation of the daemon on

Also when fooled by multiple files in "include_dir" I noticed the
include order of files seemed reverse of alphabetical order of filename
(w before l). Documentation doesn't specify if any ordering should be
expected which makes behavior non-deterministic as different orders
could have functional differences.
One example being specifying "log_dest none" in an included file which
zeros the log_dest mask in the config_recurse structure used for all
files. Thus behavior would be different depending on whether that
particular file was parsed before or after other files with log_dest
clauses setting bits in the mask.

On non-win32 readdir() is used for fetching the files and as far as I
can tell the ordering is not guaranteed and in most implementations will
depend on the file-system in use
FindFirstFile() used on win32 appear similar.

Shouldn't include order be consistent, across file-systems as well as

- -- 
Version: GnuPG v2


Back to the top