This is FASCINATING.
-
@synx508 @mattblaze @hzulla Well unfortunately cron only allows one to set the minute, not the second. AFAIK it was always understood that this time was not supposed to be precise. Just adding some randomness probably isn't to hard to do.
@casandro @mattblaze @hzulla You can do that by wrapping anything called by cron in a "sleep random number of seconds" script, it's trivial and it's not worth adding complexity to cron for in my opinion. Tools should be simple and easily understood.
-
@casandro @mattblaze @hzulla You can do that by wrapping anything called by cron in a "sleep random number of seconds" script, it's trivial and it's not worth adding complexity to cron for in my opinion. Tools should be simple and easily understood.
@synx508 @mattblaze @hzulla Yes, but that would still create the first spike, loading and executing that script.
-
@casandro @mattblaze @hzulla wrapping scripts or modifying scripts isn't what I'd call complex and is "self-declaring" and doesn't change the underlying behaviour of cron, which is something you mostly don't want because a lot of things it does *must* be done at exact times.
If you modified the syntax of crontab so particular lines had the time dither switch that would be potentially complex, if you change defaults so you had to specify "exact" that would be even worse. It's likely not complex in implementation within cron, it's complex in implementation in the real world where this stuff is old and established and making changes like that could be misconstrued etc. -
@hzulla @knowprose Apple should do something. We wouldn't even know. They play games and lie about our batteries...
-
@casandro @mattblaze @hzulla wrapping scripts or modifying scripts isn't what I'd call complex and is "self-declaring" and doesn't change the underlying behaviour of cron, which is something you mostly don't want because a lot of things it does *must* be done at exact times.
If you modified the syntax of crontab so particular lines had the time dither switch that would be potentially complex, if you change defaults so you had to specify "exact" that would be even worse. It's likely not complex in implementation within cron, it's complex in implementation in the real world where this stuff is old and established and making changes like that could be misconstrued etc.@synx508 @mattblaze @hzulla Well most cron don't guarantee precision anyhow, they were not designed for that. It's some daemon running in the background, not a real-time process.
-
@synx508 @mattblaze @hzulla Yes, but that would still create the first spike, loading and executing that script.
@casandro @mattblaze @hzulla I don't think it'd be significant compared to what *could* be unleashed by a cron job starting but I agree, there would be something measurable and consistent. If you really wanted to, the wrapper could be a binary and load from RAM disk, I guess you still have the log to consider, there's no getting away from it. Then even checking the time has a small electrical cost, I suppose you can't remove granularity completely.
-
@knowprose @hzulla Sure. (I used to run a bunch of servers. I offset many job start times, for convenience.)
-
according to the records, cron originally had only three command line options, -n, -M, and -x.
https://github.com/vixie/cron/blob/9cc8ab1087bb9ab861dd5595c41200683c9f6712/cron.c#L435-L457
-
-
@itgrrl @benjamineskola @jak2k Several have been rejected.
sounds about right
-
@SchwarzeLocke good for you. I readily admit that I didn't expect this effect to be visible on a global scale on the grid.
-
B bettina@mastodon.nu shared this topic
