Bug 1198265

Summary: crontab day of week
Product: [openSUSE] openSUSE Tumbleweed Reporter: ulfbart <ub22>
Component: OtherAssignee: Danilo Spinella <danilo.spinella>
Status: RESOLVED FIXED QA Contact:
Severity: Major    
Priority: P5 - None CC: danilo.spinella, freek, mseben, per, ub22
Version: Current   
Target Milestone: ---   
Hardware: x86-64   
OS: openSUSE Tumbleweed   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description ulfbart 2022-04-09 09:19:54 UTC 
Tumbleweed snapshot 20220402:

since years I have a job which runs all weekdays beside Saturday.

But since this update I wonder that the job was not executed anymore.

Am Sonntag, 3. April 2022, 21:00:53 CEST schrieb Dominique Leuenberger:
> ==== cronie ====
> Subpackages: cron
>
> - Update to 1.6.0:
> * Add switch -f for foreground mode
> * Fix regression in handling */x crontab entries
> * Add random within range '~' operator
> * Fix RandomScale calculation
> * crond: Fix description of '-P' option
> * Increase the maximum number of crontab entries
> * crontab: use bold colors
> - Remove upstreamed patches:
> * cronie-1.5.7-increase_crontab_limit.patch
> * cronie-piddir.patch
> - Refresh patches:
> * cronie-nheader_lines.diff
> * cronie-cron_pid.diff

If I edit it via "crontab -e" and enable the line like this:
55 4   * * 1-5         echo "OK" &>> /root/crontab.txt

I receive the error:

File /tmp/crontab.3ZC6Zr saved
crontab: installing new crontab
"/tmp/crontab.3ZC6Zr":10: bad day-of-week
Invalid crontab file, can't install.
Do you want to retry the same edit? (Y/N) 

But what is wrong since this update???
Comment 1 Andreas Stieger 2022-04-09 11:51:24 UTC 
bug 1198265 and bug 1198241 read similar and could be due to same change
Comment 2 ulfbart 2022-04-09 12:18:34 UTC 
Tested meanwhile.

crontab seams to be not running at all on any user incl. root.

also if I add the below /etc/crontab
55 4   * * SAT     root    echo "OK" &>> /root/crontab.txt
(CRON) bad day-of-week (/etc/crontab)
Comment 3 ulfbart 2022-04-09 12:23:20 UTC 
Yes, all three are based from my point of view on the same update.

1. crontab seams to be not running at all
2. interprtation of day of week is not fully functional according man pages
Comment 4 ulfbart 2022-04-10 17:13:38 UTC 
If I edit "/etc/crontab" and enable the line like this:
55 4   * * 1-5      echo "OK" &>> /root/crontab.txt

Isn't working too. But if I add only one day it is working
55 4   * * 1        echo "OK" &>> /root/crontab.txt

Preliminary solution for me was to use numbers and do a line for each day :-(
Comment 5 Danilo Spinella 2022-04-14 13:23:26 UTC 
This was indeed a regression in the latest update. I have backported an upstream commit that fixes this bug, it should be available in the next snapshot. Closing as fixed.
Comment 6 Danilo Spinella 2022-04-14 13:28:10 UTC 
(In reply to ulfbart from comment #4)
> If I edit "/etc/crontab" and enable the line like this:
> 55 4   * * 1-5      echo "OK" &>> /root/crontab.txt
> 
> Isn't working too. But if I add only one day it is working
> 55 4   * * 1        echo "OK" &>> /root/crontab.txt
> 
> Preliminary solution for me was to use numbers and do a line for each day :-(

As a sidenote, /etc/crontab should be modified directly, "crontab -e" should instead be called, which check that the crontab is correct before installing it. Indeed, when using 1-5 as days, "crontab -e" was reporting it as error, due to this regression. By changing crontab directly, cron fails silently, like in this case.

Please reopen this bug if you encounter any other problem, thank you again for the report!
Comment 7 ulfbart 2022-04-14 17:27:02 UTC 
(In reply to Danilo Spinella from comment #6)
> As a sidenote, /etc/crontab should be modified directly, "crontab -e" should
> instead be called, which check that the crontab is correct before installing
> it. Indeed, when using 1-5 as days, "crontab -e" was reporting it as error,
> due to this regression. By changing crontab directly, cron fails silently,
> like in this case.
> 
> Please reopen this bug if you encounter any other problem, thank you again
> for the report!

Thanks for your work