Allow os_log without mirroring to stderr

Originator:torarnv
Number:rdar://36919139 Date Originated:January 26 2018, 9:04 PM
Status:Open Resolved:
Product:macOS + SDK Product Version:
Classification:Suggestion Reproducible:
 
Area:
Something not on this list

Log messages sent via os_log are today mirrored to stderr via __os_log_impl_mirror_to_stderr if any of the OS_ACTIVITY_DT_MODE, ACTIVITY_LOG_STDERR, or CFLOG_FORCE_STDERR environment variables are set. The former is set by Xcode (as far as I can tell).

This may not always be desired, if for example you want to log a lot of messages that you want to inspect in Console app, but you want to limit console output to a few select messages, using e.g. printfs. 

__os_log_impl_mirror_to_stderr already has exceptions for any image in /System/Library/ or /usr/lib/ that prevents stderr output, as well as an exception if the fifth argument to __os_log_impl_mirror_to_stderr is 0x4, but I haven't been able to figure out how _os_log_impl_flatten_and_send comes up with that argument.

The workaround of setting OS_ACTIVITY_MODE, to prevent Xcode from setting  OS_ACTIVITY_DT_MODE, is unfortunately not an option, as that silences stderr output for all logs, including calls to NSLog other places in the code, were you do expect the output on stderr.

It would be nice if there was an os_ api to mark a os_log_t as not needing stderr mirroring, or if os_log by default wasn't mirrored to stderr, but CFLog and NSLog were. Thanks!

Comments

It seems the 0x4 argument to _oslog_impl_mirror_to_stderr is determined based on the MachO header having a flag indicating the image is coming from the shared cache (mh->flags & 0x80000000), which unfortunately is not an avenue to trigger the non-stderr-mirroring behavior indirectly :) An explicit API for this would be nice, thanks!


Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!