cronie-crond / cronie Goto Github PK

I believe the following verbiage in man/crontab.5 is incorrect:

Names can also be used for the 'month' and 'day of week' fields.  Use the
first three letters of the particular day or month (case does not
matter).  Ranges or lists of names are not allowed.

I perused the source code, and based on my reading (which you shouldn't trust :-) believe that the code indeed does convert weekday and month names into integers, and then uses the integers to trigger on the appropriate range (or list) of days (or months); see: https://github.com/cronie-crond/cronie/blob/master/src/entry.c#L248-L264 and https://github.com/cronie-crond/cronie/blob/master/src/entry.c#L438

I also just ran a test (just to be sure my reading of the source wasn't entirely off) using the follow crontab entries, and have been getting emails as expected all week:

0 12 * * mon-fri echo "Cronie day range test: $(date +\%a)"
0 12 * * sat,sun echo "Cronie day list test: $(date +\%a)"

I didn't try named month lists or ranges, but looking at the code, it uses very similar logic for month-names, so it seems like it should also work.

I suggest the following patch:

diff --git a/man/crontab.5 b/man/crontab.5
index 2ee9feb..abe2b1c 100644
--- a/man/crontab.5
+++ b/man/crontab.5
@@ -212,7 +212,8 @@ two hours, you can use "*/2".
 .PP
 Names can also be used for the 'month' and 'day of week' fields.  Use the
 first three letters of the particular day or month (case does not
-matter).  Ranges or lists of names are not allowed.
+matter).  Ranges and lists of names are allowed. Examples: "mon,wed,fri",
+"jan-mar".
 .PP
 If the UID of the owner is 0 (root), the first character of a crontab
 entry can be "-" character. This will prevent cron from writing a syslog

Hi,
I updated to the last cronie package from cronie-1.4.11-23.el7.x86_64.
I get this message in the yum update.
file /etc/cron.d from install of cronie-1.4.11-24.el7_9.x86_64 conflicts with file from package

Looked through the commit and couldn't find any change that is related.
Any idea what I'm doing wrong.
I ran the same thing on the same env since cronie-1.4.11-19.el7.x86_64 without an issue.

A problem which seems to crop up every so often is determining if a cron job has ended. I took a quick look to see if such an option was available, and found that an old Debian version of anacron supported the '-L' option. ('-L 2' would log when a job finished.) Looking further it seems that this option is still maintained in Debian 10, but is provided by a (somewhat large) patch applied to an older anacron. So basically this is a Debian extension.

I am curious as to why cronie does not seem to support the ability to log when jobs end. I would be willing to look into providing this ability (although probably not quite like the '-L' option. Using it on a Debian server the PID numbers were out of step, and made it a bit difficult to see when a job ended), but wondered if this idea had already been considered and rejected.

Thanks.

When a job is invoked from cron and the pam_group.so is configured to add supplementary groups it DOES NOT work as expected.

pam_group should provide membership based /etc/security/group.conf and it is working fine if you test with login or sudo.

After some tests I've compiled pam_group.so in DEBUG and I can confirm that pam_setcred in being called by cron and the module is adding the expected groups membership.

As far as I can tell those groups are being lost on cron_change_user_permanently or cron_change_groups.

Any help would be appreciated.

Tests done on a Ubuntu 20.04.2 LTS

/etc/pam.d/common-auth

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_sss.so use_first_pass
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth    optional                        pam_cap.so
auth    optional                        pam_group.so

/etc/security/group.conf

;;postgres;Al0000-2400;dev_postgres_adm,dev_app_commons,irc

Log of pam_group being called by cron

Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:pam_sm_setcred(814)] service=cron
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:pam_sm_setcred(815)] user=postgres
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:pam_sm_setcred(816)] tty=cron
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(589)] counting supplementary groups
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(608)] no supplementary groups known
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:time_now(366)] day: 02, time: 1348
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(627)] working on rule #1
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(636)] with service: passes
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(647)] with tty: passes
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(669)] with user: passes
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_time(381)] checking: 02/1348 vs. Al0000-2400
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_time(400)] Al ?
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_time(419)] day range = 0177
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_time(438)] i=5, time_end=2400, times[j]='
Mar  1 16:48:01 minasgerais cron[419269]: '
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_time(443)] times(0 to 2400)
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_time(444)] marked_day = 0177
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_time(452)] time is listed
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(681)] with time: passes
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(696)] adding dev_postgres_adm,dev_app_commons,irc to gid list
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:mkgrplist(524)] cf. blks=0 and len=0
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:mkgrplist(532)] allocating new block
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:mkgrplist(549)] found group: dev_postgres_adm
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:mkgrplist(559)] group dev_postgres_adm exists
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:mkgrplist(549)] found group: dev_app_commons
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:mkgrplist(559)] group dev_app_commons exists
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:mkgrplist(549)] found group: irc
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:mkgrplist(559)] group irc exists
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:mkgrplist(568)] returning with [0x7fffc496a958/len=3]->0x5626f2347d40
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(706)] rule #1 passed, added 3 groups
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(721)] trying to set 3 groups
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(724)] gid[0]=435833731
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(724)] gid[1]=435833738
Mar  1 16:48:01 minasgerais cron[419269]: [pam_group.c:check_account(724)] gid[2]=39

It's a forward of downstream https://bugs.gentoo.org/750728 where cronie fails on autoconf-2.69c (soon to be autoconf-2.70).

$ ./autogen.sh
/usr/bin/m4:configure.ac:1: Warning: excess arguments to builtin `m4_define' ignored
autom4te-2.70_beta2: error: /usr/bin/m4 failed with exit status: 1
aclocal-1.16: error: echo failed with exit status: 1
autogen.sh: exit on error

It happens because autoconf-2.70 slightly changed quotation around AC_INIT and fails more prominently if there is not just an email address. The following workaround seems to fix it:

--- a/configure.ac
+++ b/configure.ac
@@ -1,4 +1,4 @@
-AC_INIT([cronie],[1.5.5],[[email protected],[email protected]])
+AC_INIT([cronie],[1.5.5],[[email protected]])
 AC_CONFIG_HEADER([config.h])
 AC_PREREQ(2.60)

This was initially reported as https://bugzilla.redhat.com/show_bug.cgi?id=1374264

Description of problem:

Error message "ERROR (getpwnam() failed)" when no user specified for jobs in /etc/crontab is not
so helpful at the first.
Maybe it will be more nice to have something like "no/wrong user-name specified for this job", or similar.

Steps to Reproduce:
Put some job in /etc/crontab without "user-name"

*/1 * * * * echo "bla" > /tmp/bla

Actual results:

Error message : Error message "ERROR (getpwnam() failed)

Expected results:

Error message : no/wrong user-name specified for this job

--- Additional comment from Tomas Mraz on 2016-09-08 12:56:43 UTC ---

You've actually specified an user - user 'echo'.

And the user name is part of the message - see the 'echo' here:
Sep 8 14:53:01 vespa crond[1023]: (echo) ERROR (getpwnam() failed)

The reason why the getpwnam() failed can be various, it can be also that remote user identity server does not answer to queries.

So the message could be:
getpwnam() failed - user unknown or user identity resolution failure

--- Additional comment from Stefan Dordevic on 2016-09-08 13:13:33 UTC ---

(In reply to Tomas Mraz from comment #2)

You've actually specified an user - user 'echo'.

And the user name is part of the message - see the 'echo' here:
Sep 8 14:53:01 vespa crond[1023]: (echo) ERROR (getpwnam() failed)

Yes, exactly.

The reason why the getpwnam() failed can be various, it can be also that
remote user identity server does not answer to queries.

So the message could be:
getpwnam() failed - user unknown or user identity resolution failure

It makes sense to me.

the timestamps at the following codeline is one-second precision.

so , what if the crontab is modefied twice in one second and the timestamps is just the same。

in the following case , excute the step 2 ,4 in the same one second to make timestamps is the same .the changes of step 4 will be lost ,because of the timestamps has not changed,
1.start crond ( crond begin to start load database. )
2.modifiy crontab
3. crond load database done
4. modify the crontab again

Hi guys,
just wondering if a new field "week number" (in a year scale?i.e. 52 max? or in a month scale?i.e. 5 max? how about February?) could be introduced to crontab? so that many people are asking various "week"-dependent questions would be somewhat easier to solve? e.g. 3rd Monday of every/alternate month...etc

Hi,

If I create a file in /etc/cron.d with the following content:

MAILTO=

0 *   * * *   nobody /opt/scripts/...

MAILTO is left empty here on purpose in order to disable any email to be send as per documentation:

$ man 5 crontab
..
DESCRIPTION..
       If MAILTO is defined (and non-empty), mail
       is sent to the specified address.   If  MAILTO  is  defined  but  empty
       (MAILTO=""),  no mail is sent.  Otherwise, mail is sent to the owner of
       the crontab.

Then, the following error is throw:

2017-12-18T22:28:06+01:00 cron.info ks397423 crond[11745]: (CRON) STARTUP (1.5.0)
2017-12-18T22:28:06+01:00 cron.info ks397423 crond[11745]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 20% if used.)
2017-12-18T22:28:06+01:00 cron.info ks397423 crond[11745]: (CRON) bad minute (/etc/cron.d/www)

Thanks!

When writing new cron files it's often nice to see what will actually happen when the next event in the crontab is reached. As far as I can tell there's no "simulation" option to make this happen.

What I propose is a new command line argument that requests that cron run any command(s) that would be due to execute at that precise moment in time, like this: cron --simulate . If you leave out it just runs the next command due to occur, and also prints the timestamp for the next even that would follow that one. Thus, if you wanted to simulate several events in a row, you would first do

cron --simulate
next task occurs in 3 hours and 5 minutes:
[next, the command would be run and the result sent to stdout]

and then finally cron would print
next event would be 2 days, 5 hours, and 1 minute later, at timestamp 341414211

this would allow you to continue the chain as far as you wanted.

obviously this would only run the events in the current user's crontab.

it might be nice to have the option of just printing out what the command would be, in addition to the option of actually executing the command. you could make that an interactive choice, since obviously this is not a feature that would be of use in scripts.

When anacron parses a line in anacrontab it accidentally ignores any backslashes which are not followed by a newline and so they are removed from the command that is run. I came across this whilst trying to use the -exec action of the find command which requires a backslash semi-colon \; to terminate it correctly.

As an example consider an anacrontab line such as:

1 0 report echo "Can you see these backslashes? \\\\"

The backslashes are never output. Looking in anacron/readtab.c, function read_tab_line looks like this:

static char *
read_tab_line (void)
/* Read one line and return a pointer to it.
Return NULL if no more lines.
 */
{
    int c, prev=0;

    if (feof(tab)) return NULL;
    while (1)
    {
	c = getc(tab);
	if ((c == '\n' && prev != '\\') || c == EOF)
	{
	    if (0 != prev) obstack_1grow(&input_o, (char)prev);
	    break;
	}

	if ('\\' != prev && 0 != prev && '\n' != prev) obstack_1grow(&input_o, (char)prev);
	else if ('\n' == prev) obstack_1grow(&input_o, ' ');

	prev = c;
    }
    if (ferror(tab)) die_e("Error reading %s", anacrontab);
    obstack_1grow(&input_o, '\0');
    return obstack_finish(&input_o);
}

As far as I can tell whenever we examine a backslash i.e. prev == '\\' there's no way if can be added to input_o due to all the guards against it. So it just gets skipped over?

Currently it is possible to send mails if a cron job fails by specifying a mail address (MAILTO). Are there any plans to support custom notification scripts like sending messages to irc/mattermost/slack/telegram/... on failures? I think mails are quite old fashioned 😄

Something interesting for someone to implement as an RFE:

Unfortunately, neither $RANDOM_DELAY nor $RANDOMTIME do the trick, because they do not allow the following:

15~45 * * * * root /some/script.sh

What does it do? The /some/script.sh is run at a random time between *:15 and *:45. All I can do with $RANDOM is a sleep(1) for e.g. $RANDOM seconds. Yes, I somehow could fiddle around by adding some offset to it. But more advanced:

5 6~18 * * * root /some/script.sh

Now /some/script.sh is executed at 5 minutes after a random hour between 6 am and 6 pm. Yes, I could fiddle with $RANDOM and sleep(1) somehow again. But I even could do this:

515,3545 * * * * root /some/script.sh

How to do that with sleep(1) and $RANDOM? Yes, might still work somehow. But that's a lot of bash fiddling in a crontab. Finally, the '~' character is much more readable and admin-friendly, right?

Further bonus of '~' implementation, if I'm not mistaken: The "random within range" is sticky randomness until reload of crond, while $RANDOM is not.

See also the following mailing list discussions for the actual implementation:

• https://marc.info/?l=openbsd-tech&m=158683644314416&w=2
• https://marc.info/?l=openbsd-tech&m=158689123305224&w=2
• https://marc.info/?l=openbsd-tech&m=158683601514310&w=2
• https://marc.info/?l=openbsd-tech&m=158683644314416&w=2

Finally, I can not see how $RANDOMTIME would solve the expectation of this feature request.

Hi guys,

I would like to propose the addition of a new option that would allow us to only validate the crontab file and do NOT update the user config.

This would be very helpful in scenarios where you want to validate the crontab before actually updating the user configuration.

Examples:

• crontab file is automatically generated, but the config updates will be applied in a later moment;
• user input validation on CI/CD pipelines;

Since the edit option already validates the file, I think it should be an easy change to add this feature, cause the validation logic is already in place.

What do you guys think about that?

If you agree, I would be glad to help, making the changes and submit a PR.

Suggestion:

crontab -v <crontab_file_path>

Thanks!

Since more and more distributions are going into rolling distributions I'm rereporting this issue on github:

"
>>>> Such scenario:
>>>> - cronie is started and has some jobs run periodically; is this is
>>>> linked with
>>>> some pam libraries
>>>> - pam is upgraded to new version
>>>> - cronie is going to run job and tries to authorize it via PAM.
>>>> Unfortunately
>>>> cronie was started and is using old pam libraries while in mean time
>>>> pam was
>>>> upgraded. So old pam code tries to load new pam .so modules and that
>>>> of course
>>>> fails (new modules can be totally incompatible with old pam
>>>> libraries).
>>>>
>>>> Feb 9 13:52:01 firma /usr/sbin/crond[6592]: (root) FAILED to authorize
>>>> user
>>>> with PAM (Moduł jest nieznany)
>>>> Feb 9 13:54:01 firma /usr/sbin/crond[7282]: (root) FAILED to authorize
>>>> user
>>>> with PAM (Moduł jest nieznany)
>>>> Feb 9 13:56:01 firma /usr/sbin/crond[8037]: (root) FAILED to authorize
>>>> user
>>>> with PAM (Moduł jest nieznany)
>>>> Feb 9 13:58:01 firma /usr/sbin/crond[8718]: (root) FAILED to authorize
>>>> user
>>>> with PAM (Moduł jest nieznany)
>>>>
>>>> (Moduł jest nieznany means Module is unknown).
>>>>
>>>> It would work fine if cronie would reexec itself before running
>>>> jobs... maybe
>>>> there are other solutions.
>>>>
>>>> Anyway it's constant pain here and ususally hard to notice
>>>> immediately.
>>>> -- 



>>> Hello,
>>> this doesn't happened in "normal" stable distribution.
>>
>> That's very limited view of what's out there. There are other distributions
>> than "normal" or people even compile things themselfs without depending on
>> distributions.
>
> Hi,
>
> Just FYI - that reported cronie weakness is the most often repeated problem I
> see in last 2 years here on setups where...
>
>>
>>> API/ABI changes
>>> during release are usually forbidden.
>>
>> Here are usually allowed because we have very different approach than
>> redhat has.
>
> ... ABI changes are allowed. Counted in hundred of cases :-/
>
>>
>>> Also if I call reexec in cronie,
>>> also all other daemons should call it to live with change of API.
>>>
>>> I'm
>>> sorry, but I don't want add this change of code into cronie.
>>
>> dlopen pam libs when needed instead of linking with them then?
>
> Or better build time option to enable reexec in cronie?
>
>>
>>> Best regards,
>>> Marcela
>
>
I don't have much time for development these days. If you can send me a patch, I could include it in next version. I guess it would be needed to add option into Configure.ac and properly conditionalize the re-exec part.

Thanks,
Marcela 


"

Or if cronie detects such errors it could die with critical error instead of silently (not) working (where silently is deamon exists but doesn't run its job and only logs errors due to permanently being in fatal state).

OS: fedora 21
Ver: 1.4.12
platform: mips64
the cron daemon sometimes receive SIGSEGV signal when start.

i found some big array in the source code, use a lot of stack memory.

for example:
env.c->load_env()
char name[MAX_ENVSTR], val[MAX_ENVSTR];

then , i try implemented with malloc. and Test two days, it looks good.
another method：modify the cron service file to increase stack memory. LimitSTACK=xxx

Test script:
while true; do systemctl stop crond ; sleep 1; systemctl start crond ; sleep 1; done
about 2 hours or more, you will find err message use journalctl, and find the coredump file in /var/lib/systemd/coredump directory.

RANDOM_DELAY is set at process startup, by defining a randomized scaling factor

RandomScale = (double)random() / (double)RAND_MAX;

This is incorrect, as per specs random() returns a value within 0 ... 2^31-1. It's the rand() function which returns a value within 0 ... RAND_MAX.

On Linux/glibc and OSX, RAND_MAX is 2^31-1. But on other systems it's not, as observed on

• Solaris: 32767
• AIX: 32767

Trivial way to observe it:

#include <stdlib.h>
#include <stdio.h>

int main (int argc, char** argv)
{
    printf("%lu\n", (1lu << 31) - 1);
    printf("%lu\n", RAND_MAX);
    return 0;
}

This results in invalid scale factors, as reported in startup logs:

INFO(54211): RANDOM_DELAY will be scaled with factor 4018247% if used.

Hi. After cloning the latest git version my crontab won't install. The last commit is this one:

Add random within range '~' operator …
@opohorel opohorel committed on Nov 8, 2021

I get "bad minute", bad "hour", bad day-of-week, you name it.

01 * * * * /bin/echo Hello, world!

crontab: installing new crontab
"/tmp/crontab.ZlLH9I":73: bad minute

I reverted to the prior commit it seems back to normal.

git reset --hard 19c2e1d

When crond is launched using systemd, one more instance may be launched using /usr/sbin/crond.
This is because of change at: 5b285b4
When crond launches, it checks whether it already runs or not by looking at the pid file at /var/run/, but this no longer is a correct way of checking for another instance.

I recently found one of my host doesn't run specific cronjob file. The cronjob file is written when the host gets launched. (As part of UserData of AWS EC2 instance).

host: Amazon linux 4.14 assuming this supports inotify

Wondering if this race condition is ever possible:

1. crond loads database without the cronjob file (or when the file doesn't have content) https://github.com/cronie-crond/cronie/blob/master/src/cron.c#L319
2. Then the cronjob content is written.
3. crond adds inotify watch https://github.com/cronie-crond/cronie/blob/master/src/cron.c#L333

If this is ever possible, would it make sense to do load_database after adds watch?

/usr/local/bin/crontab -l shows this error and returns 0:

/usr/local/var/spool/cron: No such file or directory
/usr/local/var/spool/cron: mkdir: No such file or directory

I compiled the binaries according to the INSTALL file:

./autogen.sh # configure file didn't exist after cloning the repository
make
make install  # as root

In case it's useful:

• lsb_release -a output:

No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

• build-essential has version 12.6.
• /usr/local/bin/crontab -V output:
  cronie 1.5.4

Hello,

In commit a657676 you've created a limit for crontab entries (1000) to prevent DoS attack. However some of our customers and other users are hitting this limit in some reasonable edge cases. Debian has already patched this limit to 10 000 entries in 2019:

cron (3.0pl1-134) unstable; urgency=medium

• Increase maximum crontab length to 10,000 lines.
  The previous limit proved to be too low for users with edge cases.
  (Closes: #925276)

I would like to ask if you had any particular reason for 1000 entries and if you think that it would be safe to change it 10 000.

Thank you!

It can happen that a mail with the output of the job can't be sent (e.g. because of postfix misconfiguration). In that case, cron waits till the children process is finished which can cause that cron process doesn't quit and every time the cron job is repeated, a new process will be started and processes are piling up.

Maybe a timeout after that the waiting for the child process is ended could be a solution. What do you think?

Thanks!

Hello,

The code is currently either always allowing or denying access in case the SELinux class or access vector is not defined.

IMVHO, this is not OK and you should use security_deny_unknown() after the calls to string_to_security_class() and string_to_av_perm() are failing.

The man page states:

security_deny_unknown() returns 0 if SELinux treats policy queries on undefined object classes or permissions as being allowed, 1 if such queries are denied, and -1 on error.

So it should be something like

	tclass = string_to_security_class("file");
	if (!tclass) {
		log_it("CRON", getpid(), "ERROR", "Failed to translate security class file", errno);
		if(security_deny_unknown() == 0)
			return 0;
		else
			return -1;
	}

Using crontab -e without vi installed results in the error: /bin/sh: /usr/bin/vi: No such file or directory.
Please don't hard-depend on vi. As fallback, it's sane. But please prefer my setting in $EDITOR. Thanks.

Just curious why there is no APT package?

I saw some in Debian experimental repository, but no other. I would really appreciate having cronie for Debian/Ubuntu systems.

su username -c crontab -l
What this command does?

It does not list crontabs for username - for this it should be su username -c "crontab -l". It runs "crontab" with no options.

But what bare "crontab" command does? It's not documented - man page says at least one option or a single non-option argument is required. So I'd expect it to just fail with an error. But it runs an equivalent of "crontab /dev/stdin" instead, deleting the current crontab if stdin is empty. The "crontab -" also works like this (also undocumented in the man page).

The help showing when invalid option is given states "Default operation is replace, per 1003.2". I don't know the exact wording of the standard, but it does not seem to force this non-intuitive and dangerous behaviour. IMHO it just means that when the file argument is provided then the default operation is to replace the crontab with its contents.

This is a continuation of #80, which I closed by accident – sorry about that.

I dislike this being a new optional field in the cron entry.

I'm also not thrilled from the new field, but it would be compatible with *BSD cron implementations, as linked in the original PR: NetBSD/src@666eac5.

I'd prefer something similar to the - at the beginning of the entry that switches off the logging (for root only).
Or perhaps the suggestion from: https://bugzilla.redhat.com/show_bug.cgi?id=1591763#c11

I will forward the suggestions to the original requester and see what they think. Hopefully I can also persuade them to continue the discussion here, so it is present in one place.

--

In the mean time, thanks for all the feedback so far, Tomas!

I'm trying to run a web service at boot, but @reboot /home/system/.scripts/service whoogle-search doesn't work

the MAILFMT is hardcoded to source as AC_DEFINE(MAILFMT,"%s -FCronDaemon -i -odi -oem -oi -t -f %s",:

• https://github.com/cronie-crond/cronie/blob/cronie-1.5.4/configure.ac#L201-L209

and the -Fx = Set full-name of sender option is not recognized by busybox-v1.30.0:

/usr/lib/sendmail: invalid option -- 'F'
BusyBox v1.30.0 (2019-01-24 15:23:24 CET) multi-call binary.
...

https://github.com/cronie-crond/cronie/blob/cronie-1.5.4/src/do_command.c#L430

It looks like crontab throws a "path too long" error when the hostname of the machine on which the cmd is executed has a large value.
https://github.com/cronie-crond/cronie/blob/master/src/crontab.c#L756

crontab -l prints comment lines in a different color starting with version 1.5.5 (commit 8a68c5e in particular). However if crontab ends with a comment line, the color is not reset at the end of the output and the font stays colored in shell.

\033[0m should be added to output to prevent this.

As noted at https://bugzilla.redhat.com/show_bug.cgi?id=1838180

there should be at least some way to disable all colorization for the tool itself. at a system level, redhat has "COLOR none" in /etc/DIR_COLORS for ls which stops "--color=auto" alias from activating. there is also a no-color initiative at https://no-color.org/

You can do crontab -l | cat but I agree with the bug reporter that a way to disable the colours through config would be preferable. Even just a --no-color option would be an improvement.

The generated mails are missing a MIME-Version: 1.0 header which is mandatory for Content-Type. E.g. RFC 2045 says

Messages composed in accordance with this document MUST include such
a header field, with the following verbatim text:

 MIME-Version: 1.0

Without this header, sendmail or either MTAs might reject cronjob notification mails with

554 5.6.1 Eight bit data not allowed

step 1：crontab -e，create a task that executes every minute
step 2：Enter the wrong password multiple times during login，automatically lock for n minutes。
When the cronie task is executed, it will automatically unlock。

Right now, right as the job begins running, cronie spawns the mail command and pipes all output to it. For longer-running jobs and with mailers that connect to MTAs right away, the MTA times out after a certain time, completely losing any cron output.

Debian's crond fixed this 9 years ago (see also a relevant bug report).

Not sure if this behavior is intended, but cronie isn't reading any crontab files in /etc/cron.d/ when their mtime=0 (epoch).

This happened to me on a root filesystem created with squashfs-tools-ng, which by default sets all modification times to zero.

This isn't much of a problem for me as the workaround is trivial (just set a nonzero mtime), but I thought I'd let you know that this a failure mode that can happen.

I don't remember updating cronie recently, but could've been updated, but didn't restart the service.

Is it some new behaviour? What could be triggering it? I'd like to revert it to the state, where only "stderr" would trigger the mail.

Given the following crontab:

*	*	*	*	*	longusername	/usr/local/bin/foo.sh
*	*	*	*	*	user		/usr/local/bin/bar.sh

crond does not strip the extraneous tab before the second command, leading it to attempt to execute a command beginning with a tab. If one executes less(1) on the system log file, one observes:

2021-03-20T04:00:01+00:00 CROND[20901]: (longusername) CMD (/usr/local/bin/foo.sh)
2021-03-20T04:00:01+00:00 CROND[20902]: (user) CMD (^I/usr/local/bin/bar.sh)

This is due to less(1) rendering a literal tab as ^I.

Similarly, if one uses spaces instead:

*       *       *       *       *       longusername    /usr/local/bin/foo.sh
*       *       *       *       *       user            /usr/local/bin/bar.sh

Then one observes:

2021-03-20T04:05:01+00:00 CROND[20907]: (longusername) CMD (   /usr/local/bin/foo.sh)
2021-03-20T04:05:01+00:00 CROND[20908]: (user) CMD (           /usr/local/bin/bar.sh)

I'm sure there must be platforms out there where this would fail. It also makes the system log render like garbage, and may upset some log integration tools that aren't expecting tab characters or leading whitespace. All the user wants, or at least this user wants, is for their fields to line up from one line to the next, to make the crontab easier to read and modify.

Unless I'm missing something obvious, MAILFROM works correctly in a crontab, but it gets ignored in an anacrontab.

Crontab example:

[email protected]
[email protected]
*  *  *  *  *  echo "error" 1>&2

This correctly sets From Header to [email protected].

While
Anacrontab example:

[email protected]
[email protected]
@daily       5       test              echo "error" 1>&2

This has From Header set to Anacron <root>.

Problem is, gmail blocks anacron email with reason 'From' header has non compliant domain name.

Mails are sent using sendmail, which is symlinked to msmtp.

Is Anacron supposed to ignore MAILFROM?

As reported at https://bugs.mageia.org/show_bug.cgi?id=27480:

/etc/cron.hourly/0anacron checks for ac power indicator in
/sys/class/power_supply/AC/online or /sys/class/power_supply/ADP{0..9}/online

The laptop in use uses
/sys/class/power_supply/ACAD/online so cron.hourly assumes the laptop is on
battery and never runs cron.daily, weekly, etc.

A patch was supplied but it won't apply to latest changes in master. It's a matter of adding ACAD as a path to check.

My Fedora 33 system updated its cronie-anacron package to 1.5.6 yesterday, and my daily cron jobs did not fire this morning.

The /etc/cron.hourly/0anacron file queries all power supplies to determine if any have AC power as of commit ba79def. However, this particular system is an old iMac without a battery, though it does have a Bluetooth mouse which registers its battery in /sys/class/power_supply/hidpp_battery_0:

Device: /org/freedesktop/UPower/devices/mouse_hidpp_battery_0
  native-path:          hidpp_battery_0
  model:                M305
  serial:               101f-97-e9-79-7e
  power supply:         no
  updated:              Sun 21 Mar 2021 08:53:25 AM EDT (65 seconds ago)
  has history:          yes
  has statistics:       yes
  mouse
    present:             yes
    rechargeable:        yes
    state:               unknown
    warning-level:       none
    battery-level:       unknown
    percentage:          50% (should be ignored)
    icon-name:          'battery-missing-symbolic'

This mouse battery device is causing the anacron jobs to not run.

Steps to reproduce:

user@linux:~> crontab -l
SHELL=/bin/bash         
                                                                               
* * * * *               echo "date1 $(date)" >> ${HOME}/temp/cronie_test
* * * * *               echo "date2 $(date)" >> ${HOME}/temp/cronie_test       

result with cronie-1.5.2:

user@linux:~> cat ~/temp/cronie_test
date1 Sun Mar 17 15:00:01 CET 2019
date2 Sun Mar 17 15:00:01 CET 2019
date2 Sun Mar 17 15:01:01 CET 2019
date1 Sun Mar 17 15:01:01 CET 2019
date2 Sun Mar 17 15:02:01 CET 2019
date1 Sun Mar 17 15:02:01 CET 2019
date2 Sun Mar 17 15:03:01 CET 2019
date1 Sun Mar 17 15:03:01 CET 2019
date2 Sun Mar 17 15:04:01 CET 2019
date1 Sun Mar 17 15:04:01 CET 2019

result with cronie-1.5.3:

user@linux:~> cat ~/temp/cronie_test
date1 Sun Mar 17 15:10:01 CET 2019
date1 Sun Mar 17 15:11:01 CET 2019
date1 Sun Mar 17 15:12:01 CET 2019
date1 Sun Mar 17 15:13:01 CET 2019
date1 Sun Mar 17 15:14:01 CET 2019

See also downstream bug report: https://bugs.gentoo.org/680764

I could not see in the current docs if ranges over midnight are valid or not.

I would like to read in "man 5 crontab" if this is valid or not:

05 22-5 * * * my_command.

Does 22-5 expand to 22,23,0,1,2,3,4,5?
Here are the current docs: https://github.com/cronie-crond/cronie/blob/master/man/crontab.5#L197

Please forgive me, if I was blind.

As in the latest version of cronie 1.5.5, there is enabled Anacron by default, which can not be compiled on musl.

anacron/readtab.c:33:10: fatal error: obstack.h: No such file or directory
 #include <obstack.h>

I solved it by BKPepe@a7eb66a, afterwards more warnings and error appeared:

anacron/readtab.c: In function 'read_tab_line':
anacron/readtab.c:99:21: warning: implicit declaration of function 'obstack_1grow' [-Wimplicit-function-declaration]
      if (0 != prev) obstack_1grow(&input_o, (char)prev);
                     ^~~~~~~~~~~~~
anacron/readtab.c:110:12: warning: implicit declaration of function 'obstack_finish'; did you mean 'obstack_chunk_free'? [-Wimplicit-function-declaration]
     return obstack_finish(&input_o);
            ^~~~~~~~~~~~~~
            obstack_chunk_free
anacron/readtab.c:110:12: warning: return makes pointer from integer without a cast [-Wint-conversion]
     return obstack_finish(&input_o);
            ^~~~~~~~~~~~~~~~~~~~~~~~
anacron/readtab.c: In function 'register_env':
anacron/readtab.c:143:10: warning: implicit declaration of function 'obstack_alloc'; did you mean 'obstack_chunk_alloc'? [-Wimplicit-function-declaration]
     er = obstack_alloc(&tab_o, sizeof(env_rec));
          ^~~~~~~~~~~~~
          obstack_chunk_alloc
anacron/readtab.c:143:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
     er = obstack_alloc(&tab_o, sizeof(env_rec));
        ^
anacron/readtab.c:148:16: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
     er->assign = obstack_alloc(&tab_o, var_len + 1 + val_len + 1);
                ^
anacron/readtab.c: In function 'register_job':
anacron/readtab.c:182:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
     jr = obstack_alloc(&tab_o, sizeof(job_rec));
        ^
anacron/readtab.c:191:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
     jr->ident = obstack_alloc(&tab_o, ident_len + 1);
               ^
anacron/readtab.c:197:17: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
     jr->command = obstack_alloc(&tab_o, command_len + 1);
                 ^
anacron/readtab.c: In function 'register_period_job':
anacron/readtab.c:232:8: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
     jr = obstack_alloc(&tab_o, sizeof(job_rec));
        ^
anacron/readtab.c:252:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
     jr->ident = obstack_alloc(&tab_o, ident_len + 1);
               ^
anacron/readtab.c:258:17: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
     jr->command = obstack_alloc(&tab_o, command_len + 1);
                 ^
anacron/readtab.c: In function 'read_tab':
anacron/readtab.c:402:5: warning: implicit declaration of function 'obstack_init' [-Wimplicit-function-declaration]
     obstack_init(&input_o);
     ^~~~~~~~~~~~
anacron/readtab.c:408:2: warning: implicit declaration of function 'obstack_free'; did you mean 'obstack_chunk_free'? [-Wimplicit-function-declaration]
  obstack_free(&input_o, tab_line);
  ^~~~~~~~~~~~
  obstack_chunk_free
anacron/readtab.c: In function 'arrange_jobs':
anacron/readtab.c:444:6: warning: implicit declaration of function 'obstack_grow' [-Wimplicit-function-declaration]
      obstack_grow(&tab_o, &j, sizeof(j));
      ^~~~~~~~~~~~
anacron/readtab.c:448:15: warning: assignment makes pointer from integer without a cast [-Wint-conversion]
     job_array = obstack_finish(&tab_o);
               ^
anacron/readtab.c: At top level:
anacron/readtab.c:43:23: error: storage size of 'input_o' isn't known
 static struct obstack input_o;   /* holds input line */
                       ^~~~~~~
anacron/readtab.c:44:23: error: storage size of 'tab_o' isn't known
 static struct obstack tab_o;    /* holds processed data read from anacrontab */
                       ^~~~~
make[4]: *** [Makefile:706: anacron/readtab.o] Error 1

Anyway, when I used --disable-anacron, I am able to compile cronie just fine and it works.

Issue is that it causes that generated by github tar ball has base directory is cronie-cronie- .
Cheers :)

As far as I know @weekly means 0 0 * * 0

At the moment DOW_STAR flag is set for this definition, but probably it wanted to be DOM_STAR. It is easy to miss that one letter difference.

https://github.com/cronie-crond/cronie/blob/master/src/entry.c#L182

I'd like to suggest an additional security feature.
Cron refuses to execute commands/scripts where any of the following apply:

1. file to be executed is not owned by the current user
2. file to be executed is group writeable (potentially with an exception if group is named the same as user)
3. file to be executed is world writeable
   If any apply, cron outputs an error message instead of the command / script output

The main idea is to avoid execution by root of files editable by non privileged users, but is applicable in general to any user.
While not 100% foolproof (it does not stop inclusion of other files in scripts) it provides a first level of protection for an issue which may not be apparent to users setting up a cron job that has to be executed by root

The feature could be deliberately overridden by a command line parameter.

#17 (comment)

Because hardened mail servers will refuse to accept mail without authentication, it would make sense to provide MAILFROM with the ability to substitute at least $USER variable.

Global configuration MAILFROM=cron+$USER@server resulting in cron+maria@server e-mail would be more clear than just cron@server.

crontab -l [-u] should enumerate all the jobs for the user, including all entries in various /etc/cron.*/* . Only the daemon itself can accurately report its internal state, without possible race conditions, so one should not rely on manually parsing entries in /etc. The issue has been reported also on RedHat bugzilla (not much is moving there, but at least the problem seems to be acknowledged) and seems to have been always present since the advent of /etc/cron.*/*. Also there should be a mean to immediately refresh the configuration, without waiting for the file changes notification.