Cron job command within the mirrors wiki doesn't seem to work

[Dranick]

My cron job crashes with
/bin/sh: (RANDOM\%3500)+1: syntax error: invalid arithmetic operator (error token is "\%3500)+1")
however if I take out the backslash and only leave
sleep $(((RANDOM%3500)+1)) it does seem to work.

Maybe point 3 in the https://wiki.almalinux.org/Mirrors.html page should be changed?

[codyro]

I believe the listed command is correct due to how crontab handles % characters:

Percent-signs (%) in the command, unless escaped with backslash (),
will be changed into newline characters, and all data after the
first % will be sent to the command as standard input.

When running this command manually in the shell, it will error out as you noted. When ran in a crontab, it should run successfully.

[root@cron-test ~]# crontab -l
* * * * * echo $(((RANDOM\%3500)+1)) >> /tmp/cron-orig.log
* * * * * echo $(((RANDOM%3500)+1)) >> /tmp/cron-new.log

[root@cron-test ~]# rm -f /tmp/cron-*.log

[root@cron-test ~]# ls /tmp/cron*.log
/tmp/cron-orig.log

[root@cron-test ~]# cat /tmp/cron-orig.log
946
734

The second command fails out when ran in the crontab in this instance, while the original command produces the expected output.

Can you verify that the cron is actually failing due to a syntax error, or is something else happening when the command is being ran?

[Dranick]

What exactly do you need from me? If you run the command from bash it will fail:
https://bit.ly/3N8TEMw
If I leave the command with a backslash, the cron job will not be executed;
If I have it like: https://bit.ly/3Pcevkr it will properly work with the rest of the command

Should you want to stick to the crontab manual, fine; don't change it; people will adapt regardless

I cannot be academic about it; I don't master bash; I am merely telling you that two people already went beyond the man pages of crontab and found that the escaping backslash doesn't work; perhaps a significant one from AlmaLinux should ask the crontab developers why; I am a mirror provider with an error hoping for a resolution from the community

[codyro]

It is expected that the command from the crontab line will fail when running it in the shell manually due to it having the extra \ to escape the % to account for how cron handles them.

If you're running the command outside of the crontab, you would want to remove the (\), as it's not necessary when running it in the shell.

If I leave the command with a backslash, the cron job will not be executed

I'm unable to replicate this using a stock AlmaLinux 8 install. Can you try the following for me and let me know what you see:

1. Add the following two lines in your crontab (crontab -e):

* * * * * sleep $(((RANDOM\%3500)+1)) && echo "Yay, I worked!"
* * * * * sleep $(((RANDOM%3500)+1)) && echo "I did not work"

2. Wait 1~ minute, then check the contents of /var/log/cron file

If you see something like this, that means the command in the wiki should be working as intended:

Jun 15 19:26:01 cron-test CROND[1319991]: (root) CMD (sleep $(((RANDOM%3500)+1)) && echo "Yay, I worked!")
Jun 15 19:26:01 cron-test CROND[1319992]: (root) CMD (sleep $(((RANDOM)

[Dranick]

I am telling you that I have ran this command within webmin crontab and it failed; I have left this command to simply be executed by crontab and it has never updated the timespamp.txt file while having the \ in the command. After removing it, the timpestamp.txt started to reflect the date I was in.

Should you want to acknowledge this or not it is up to you.

[jonathanspw]

Can you try from within shell using crontab -e directly as opposed to Webmin's interface? There's no telling what it may or may not be doing to the raw command.

[codyro]

I think the Webmin portion is the missing piece we needed. Do you know if it's adding the command to the /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly , or /etc/cron.hourly directories instead of in the crontab directly in /etc/crontab or /etc/cron.d?

I believe if it's using the /etc/cron.* directories, the command will be ran using run-parts and as such be treated as a normal shell script which would not require the % sign.

@jonathanspw I need to verify that is the behavior we're seeing here, but if so I think we should consider either a different command that's more POSIX compliant / less finicky if being ran outside of the crontab.

[Dranick]

I am getting

Jun 16 12:12:01 hosting CROND[1141219]: (root) CMD (sleep $(((RANDOM)
Jun 16 12:12:01 hosting CROND[1141220]: (root) CMD (sleep $(((RANDOM%3500)+1)) && echo "Yay, I worked!")

[codyro]

It looks like the crontab line is proper and working as intended, however due to this causing confusion and being a bit ambiguous, we're going to provide alternative instructions for a systemd timer.

I'm going to be closing this issue. You can follow the changes in #277