Hey fleet team, We are suffering a weird issue. That is osquery Config API will update host intervals (distributed_interval, logger_tls_period, config_refresh). But, at the same time, distributedWrite will also update the same fields in osquery_flags query. That means if we change our these three intervals in table app_config_json. distributedWrite will write it back to what osquery_flags configured. This looks not correct, please help to give us some advises. Thanks!

Hi @Jian Zheng! Can you walk me through what you’re doing on your end step by step? The distributed write is likely a red herring here as that is just osquery checking in with query results and there aren’t any queries that would result in changes to the Fleet app config or the osquery config sent to hosts.

Hey @Kathy Satterlee, Thanks for response! 1, I changed my app_config_json with some updated intervals value. it's expected that the config API will update Hosts DB record with those in interval fields. The DB record did update by Config API. 2. However, I noticed that the host DB record intervals fields changed back to old values. I think this is because, one distributed write API called and update the host record with those with osquery_flags query result. The weird thing is both Config API and distributed write update the same fields of host DB record. But, their data source is from different places.

When you say “host DB record”, do you mean the Fleet database, or the host’s local osquery database?

Fleet database

Can you send over some screenshots showing that data changing? I think I’m missing a key point somewhere.

I think code may help you to understand this case: Config Updated interval here: https://github.com/fleetdm/fleet/blob/main/server/service/osquery.go#L501-L505C3 Distributed write update the intervals here: https://github.com/fleetdm/fleet/blob/main/server/service/osquery_utils/queries.go#L199 So in the case, Config API updates the host intervals source from app config json. Then right after osquery_flags result in distributed write also try to update the intervals fields. At the end, host intervals field will change back by distributed write.

Yes, that would update the host details, but it would just reflect the current state of the host. It still sounds like the root of the issue is that the config isn’t applying correctly.

@Kathy Satterlee the question is once osquery config API change the app_config_json with a new val, why distributed_write would change it back? if you check the logic of distributed_write, you can see that distribtued_write traverse all the detail query includes osquery_flags which comes from agent, and the val in it comes from osquery flags file, so even we change the value by agent options, the value in hosts table will be covered with original value after a while. I want to know why would it happen?

If the config applied correctly, the value returned by the detail query would be the value set in the config.

ok i get your points, so the problem is the cfg not applied, so the result of detail query returns the original val, and cover back the data in hosts table.

Exactly. Somehow, the config is changing on the host.