Okay we had a similar item happen to us and we used OSquery to track it down (Via Symptoms)

hey all, I understand that in mac, the equivalent to `ntfs_journal_events`is

file_events

, correct? wondering why it is that my

file_events

table appears active, yet with no subscriptions and no events. I've my FIM category defined via config.

Tagging back on to @allister’s reply above to see if anyone else has any suggestions on getting opendirectoryd logs into ASL. New to Apple sys admin and Google not terribly helpful. I see opendirectoryd logs in Console under Devices, but I cannot find a specific log file that the daemon is generating to even add to the asl.conf. Looking to capture a log line such as this to then retrieve with osquery via the asl table.

Authentication failed for <private> with ODErrorCredentialsInvalid

Anyone can point me to some good tutorial/guide/docs about how to codesign package up and distribute a Mac application running as Daemon that is using Endpoint Security? I have the entitlement already. I managed to run a sample app (the one on the Apple dev site) with SIP enabled. Distribution is the next step. I have read that giving the app Full Access Disk and permission to run can be automated ? it looks like the only source is Apple docs which are somewhat lacking of details most of the time. Appreciate any help

M1 seems to be reported as i486 cpu

hardware_model = MacBook Pro (14-inch, 2021)
          cpu_type = arm64e
       cpu_subtype = ARM64E
         cpu_brand = Apple M1 Pro
cpu_physical_cores = 10
 cpu_logical_cores = 10
   physical_memory = 34359738368

:feelsgoodman:

I guess this is a pretty fundamental question that could therefore go in general, but… So the scheduler takes intervals from the queries and get splayed out if the counters for multiple land around the same time client-side. That statement is enough of a roller-coaster to say I can't defend the server from a thundering herd, it's all local and something called an epoch is supposed to be the only visibility server-side as to when intervals all started, but that's a timestamp and not unix 1970-whenever

The scheduler itself appears to be in-memory and directly relates to the osqueryd service…. which means if launchd itself wants to mess with it due to system pressure in some way… the whole schedule is lost and counters need to reset again (which would probably only occur after next config check-in)? Also, can I see/predict when a query is supposed to run next, discounting splay?

This seems like a specifically designed system without hard assurances that the 'mail will get through' if I have queries scheduled for e.g. longer than ~a few days - if a client restarts on a regular basis there's no continuity handled by launchd, it's just magic 8 ball 'try asking again', delayed to the point that it makes my server look broken …and I will fully admit I'm holding it rong, but I had majority 7-day query intervals and was getting one out of 4 or half of the results I would have expected, and c++ is not quite easy to follow, control-flow wise, to really understand why it was behaving this way

I’m not sure I understand your question. (But yes, this does sound broader than macOS.) If I understand osquery, and your question, I think you’re correct. The scheduler schedules queries with a lose guarantee of “Every N in uptime”. So machines that spend a lot of time off will also appear to be missing data.

I don’t remember if “uptime” is host uptime, or osquery uptime here.

osquery uptime. The scheduler starts and ticks every second (+ some possible drift), When the amount of seconds passed is a multiple of the query splayed interval, the query will run

so there’s no pre-calculated point in time when the query will run

Actually I should say, when the amount of steps which have a base duration of 1 sec + drift is a multiple of the query splayed interval.

That means it will eventually run, and system restarts should not impact it.

Hum no, because at every restart the steps counter restarts from 0

was about to say, I don't know how it would retain the schedule past a reboot if it's retained in memory and the daemon being HUP'd also drops it

so, a subset of a subset when it comes to possibility that 'the mail will get through' - that sets my expectations accordingly

or more precisely, it restarts at the unix timestamp that the scheduler starts, so indeed there’s a particular behavior where if the timestamp is a multiple of the splayed interval, then it will run

I recalled it was resetting it to 0, but it’s actually using a unix timestamp as the first step value

spreading this out in a clear/universal-enough way that every platform can find it intuitive is surely impossible (as projects like pleaserun remind me of) but I made myself a pretty lousy completion rate by scheduling workstations at the maximum possible upper limit

visualizing uptime and DAEMON uptime across my fleet sounds interesting, as well

I’m not immediately sure why we are using a timestamp as the first value. This might explain the fact that sometimes I have seen queries run almost immediately when osquery starts, probably because the initial timestamp was a multiple of the query interval and it almost seemed like it was recovering time lost during the downtime indeed. But it’s a bit more “r (in the sense that even if normally when they run is relative to when they start, even the precise second osquery starts at counts).

I wonder if it would be reasonable to store this across restarts. So we don’t reset that counter when we restart osquery

Looking for a sanity check

I can't seem to get that to return anything

(unless I remove the

last="1h"

part)

currently testing with orbit shell

% orbit version
orbit 0.0.8
commit - 5e7c4442f703d32f14031cbfd0eb5dc474e5efaf
date - 2022-03-25T17:37:44Z

I have confirmed that running it alone has output

log show --last=1h --predicate "processImagePath contains 'mdmclient'" --style json