Persisted log entries disappeared?

Each system log entry has time to live (TTL) value. You can see evidence for this in various places within the UI. For example:

% sudo log stream
… TTL  
… 0    fseventsd: (libsystem_info.dylib) Resolve user group list
…
… 7    WindowServer: (SkyLight) [com.apple.SkyLight:KeyboardEvent] kCGSEventKeyUp …

AFAIK there’s no supported way to override that, but if you poke around in /System/Library/Preferences/Logging on your Mac it’s not hard to see how it works.

WARNING As with all implementation details, there’s no guarantee that this will actually work, or that it hasn’t worked differently in the past, or will work differently in the future. So don’t build knowledge of this into a product that you ship to a wide range of users.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Thanks to Quinn's hint, I was able to successfully log collect tonight's and yesterday's messages this morning using log show!

I have also realised that log stats will also display ttl stats (and predicate has a documented timeToLive field):

% log stats --archive /tmp/system_logs.logarchive --predicate 'subsystem=="com.example.MyApp"'

...

ttl:                [        1day      3days      7days     14days     30days ]
                    [           0          0          0          2         51 ]

...

Although sometimes the ttl summary is omitted, in particular (but not only) if all messages seem have the same ttl.

The OSLogPreferences entry in my Info.plist now looks like this:

	<key>OSLogPreferences</key>
	<dict>
		<key>com.example.MyApp</key>
		<dict>
			<key>DEFAULT-OPTIONS</key>
			<dict>
				<key>Level</key>
				<dict>
					<key>Enable</key>
					<string>Debug</string>
					<key>Persist</key>
					<string>Debug</string>
				</dict>
				<key>Enable-Private-Data</key>
				<true/>
				<key>TTL</key>
				<dict>
					<key>Default</key>
					<integer>21</integer>
					<key>Info</key>
					<integer>21</integer>
					<key>Debug</key>
		      <integer>21</integer>
          <key>Error</key>
          <integer>21</integer>
          <key>Fault</key>
          <integer>21</integer>
				</dict>
			</dict>
		</dict>
	</dict>

Many thanks Quinn!

I was discussing this thread with a colleague and they pointed out an issue with your OSLogPreferences setup. While it’s not a bug per se, it is something you should know about so you can make a conscious decision about whether you want to change your setup or not.

Right now your setup changes the TTL for all categories in your subsystem (com.example.MyApp). That’s not something we’d recommend, because it unnecessarily increases pressure on the logging system. By doing that you cause the logging system to hit its limits earlier, which makes it less likely that the really interesting log entries will survive.

A better option is to:

• Classify your log points into those that need to persist for longer and those that don’t.
• Put them in separate categories.
• Adjust the TTL only on the categories for the priority group.

The TTL is a type of priority and, as an old friend of mine once said, the nature of priority is that for you to ‘win’ someone else has to ‘lose’. If you give all your log entries high priority, it’s the same as giving none of them high priority.

Oh, one other thing. Given that you’re using OSLogPreferences to configure this stuff, you should think carefully about whether you want different values for that property in your Debug and Release configurations.

I believe that iOS will honour OSLogPreferences in your shipping app. However, releasing your app that way would be problematic because of the priority issue I talked about above. If everyone did that, it would compromise Apple’s ability to debug its own problems, and I can imagine that’d result in us disabling, or limiting, the utility of OSLogPreferences. And no one wants that.

So my advice is that you completely remove OSLogPreferences from your Release build. And if you leave it in, think very carefully about what values it contains.

Oh, and regardless of the log pressure issue, you don’t want to ship with Enable-Private-Data O-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"