Re: [mosquitto-dev] Duplicated log when using upstart>=1.4 can break sys

[Mikkel Kirkgaard Nielsen <miki@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
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; http://www.itp.uzh.ch/~dpotter/howto/daemonize.

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
stdout/err.


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
(http://pubs.opengroup.org/onlinepubs/9699919799/functions/readdir.html,
https://utcc.utoronto.ca/~cks/space/blog/unix/ReaddirOrder).
FindFirstFile() used on win32 appear similar.

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

- -- 
    Mikkel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJWi/DSAAoJEJ2luFWzaTSah6QH/jAak65pS8jU/OATnGYlUNY9
NfaK2FrdCWtJMD6prVAGrtd2NkoY9bDLw5KffdC5mJcMZpXJJH1T4eGGl3meCBOI
/pn03Ahtau7Cl+ALCknq2QH9ROXKAMEA2oouyJ5boqOd0FhA7LJwIj7ToNxDZhTs
3Qe4h/e5IamWulstXbAqTQXH6qw2nHmfdZqwj5dkekohyxmqByI3HcNh2EF/eR5l
7Sov3au13CXwxDtqEpttmS2qAiBWhMWWuVOrEMkiJqPtrnUKoH8K/j/Said0x+O6
XmJWbErEjdhpk4znL7g6A5RGSMYVMaEcEcld3u/3NIHpJj+QSZ1aCbTh9t44nko=
=ubAn
-----END PGP SIGNATURE-----