Tips or Tweaks for controlling when a daily ConfigSource runs?

Definitely try touching/editing the configs at a very specific time(s) throughout the day, then see how that effects the timing of things.  You might be able to really kludge it that way and that gives you band-aid time.  :-)

I can’t imagine this would be pegged to Collectors boot time since you’d probably see this pin to a specific time no matter what with regular Collector reboots.

• I want the daily results shown in the text so that people can make note of when an action happened

A good reason to think about LM Logs, unless you’re not licensed for it.

• I got in the (bad?) habit of doing all our platform scripts as config sources, all running against our portal resource object, so habit I suppose.

I do this too, although I run mine as datasources so that i can output certain script variables as datapoints at the end of the script.

• I generally want the code to be native groovy or powershell anyway, because in case I get hit by a bus or something, I want someone else coming in to look at the config source to be able to literally see the code there in the LM platform.

A good reason to request native python support in LM. I can’t believe it’s 2024 and we still don’t have it. I’ve been told in the past that it isn’t done because “it would be hard keeping all the virtual environments and stuff from conflicting.” Seems like a cop out to me.

We learned recently if you do disable the instance, you still have to wait till past the point when it would normally pull before re-enabling.

Just wondering if anyone has any tips or tricks? I’ll probably just rewrite this to run hourly but act only on a specific hour of the day. But just fishing for ideas.

This is the way. There’s no definitive way of controlling it from LM’s side. You might have luck editing it at a specific time, but a collector going down could undo it.

I assume you’re doing it as a configsource because you want to save the output of the script as a blob of text, readable from LM? Have you considered containerizing your python script and pushing the logs to LM Logs via the API? 

The old-fashioned way to do this would be to run it using cron (wrapped in a job monitor wrapper) You wouldn't have the diff (unless you saved the diff-able output in a file with its own configsource) but it would happen when you want it to. 
https://www.logicmonitor.com/support/logicmodules/batchjobs/setting-up-batchjob-monitoring/batchjobs

My main reasons (probably all bad? :)) would be:

• I want the daily results shown in the text so that people can make note of when an action happened
• I am in a weird position where I dont have easy access to any collectors where the python would run. When I “inherited” the “portal admin” dutues all of a sudden, I inherited a bunch of python scripts my predecessor wrote that just run on a windows collector. But I dont really have easy access to that collector, so I ported all of them away from external python (there were only a few). It is super tedious to have to get permission to maintain the code each time. So I wanted it all in-platform for LM.
• I generally want the code to be native groovy or powershell anyway, because in case I get hit by a bus or something, I want someone else coming in to look at the config source to be able to literally see the code there in the LM platform.
• I got in the (bad?) habit of doing all our platform scripts as config sources, all running against our portal resource object, so habit I suppose.

As for LM Logs, I’ve never had need to use them. I think there are some basic log-related functionalities I’ve never needed to use, and I seem to recall that the fancy LM Logs thing is a pay-for feature. Not sure.

Oh and for any seeming discrepancies in “inherited a bunch” and “only a few”, the first descriptor was emotional, the second was literal. :) I ported maybe 12 of them off python and over to groovy (they were already configsources someone else wrote using external python). :)