[cron] sleep random seconds (<59), if not interactive or forced #5215
Conversation
acmesh-official#944 (comment) Let's Encrypt employee said in the comments "we do see peaks at the beginning of minutes and even seconds; the finer-grained time randomization, the better." This adds a random amount of sleep second before beginning the cron job. I considered reading from `/dev/urandom` and so on, but we aren't doing anything security critical here so I thought that just using the process number modulo 59 (the largest prime <= 60) should give decent variability across the systems. The starting hour and minute are already randomized during the installation.
|
Unfortunately that code doesn't work on OpenWrt which is ash and not bash. Also, a sleep of 1-5 or 55-59 would probably defeat the purpose due to being too close to the peaks at the beginning of each second. So, playing around with it what about a random number between 6 and 54 seconds? Working on both: |
|
I don't have an OpenWRT here, but $ /bin/dash
$ echo $SHELL
/bin/bash
$ dpkg -l | grep dash
ii dash 0.5.12-2 arm64 POSIX-compliant shell
$ echo $$
939274
|
|
Is that test broken or what happened there? |
And $RANDOM isn't POSIX standard. You can test that with #!/bin/sh
echo $RANDOMCompared to #!/bin/sh
echo $$ |
|
Thank you for the info. Since the PID won't change but on reboot, what would be the solution to make it random like $RANDOM? |
|
Check how it's done here https://github.com/acmesh-official/acme.sh/blob/dev/acme.sh#L6045 |
|
@user8446 Of course you will get the same process within the same shell session. The cron job gets a new process id every time. Google how POSIX process IDs work if you want to know more. $ dash -c 'echo $$'
3317086
$ dash -c 'echo $$'
3317116
@vmmello I literally referenced that in the first comment. Imagine a hypothetical It would be zero always since the cron job starts when the minute changes. |
Seems like |
`docker-compose` was removed in actions/runner-images#9692
|
The staging tests seem to be broken at the moment, but the all the other tests pass now. |
#944 (comment)
A Let's Encrypt employee said in the comments "we do see peaks at the beginning of minutes and even seconds; the finer-grained time randomization, the better."
This adds a random amount of sleep seconds before beginning the cron job. I considered reading from
/dev/urandomand so on, but we aren't doing anything security critical here so I thought that just using the process number modulo 59 (the largest prime <= 60) should give decent variability across the systems. The starting hour and minute are already randomized during the installation.