1

I have been trying for a long to make the crontab entries to run, but it doesn't matter what Time / schedule I enter, it doesn't seem to work. I have confirmed my current time zone with date command & /etc/localtime for the symbolic link.

How do I know that cron is not working?

My script calls $date (date and time or running) in it to print within the output log, but when I modify the crontab entry to a specific time, it doesn't reflect that time, only the time of last manual execution.

Furthermore, I know that the script does run as I have run it manually and verified the output log, so it's not due to triggering a script error. Yes, rc-service crond restart has also been applied.

Someone, please suggest any avenue to investigate or troubleshoot further.

Here is my crontab entry, please ignore the 'weekly' naming. Redacted timezone entries are Continent/Timezone crontab entry

Here I am providing the script, as there is a suspicion regarding this

This is under root cron so privileges are not an issue.

#!/bin/sh

# Log file for updates
LOG_FILE="/var/log/alpine_weekly_update.log"

echo "--- $(date) ---" >> "$LOG_FILE"
echo "Starting Alpine Linux weekly update..." >> "$LOG_FILE"


apk update >> "$LOG_FILE" 2>&1
apk upgrade >> "$LOG_FILE" 2>&1
# &1 is to differentiate from a file name(str or int) but as a desctiptor, here it will redirect both the stderr,and stdout to the logfile



# Check for kernel updates:
if [ -f /var/run/reboot-required ]; then
     echo "Reboot required after update. Rebooting Now" >> "$LOG_FILE"
     reboot
fi

echo "Alpine Linux weekly update finished." >> "$LOG_FILE"
echo "-----------------" >> "$LOG_FILE"

Update:

After a whole day of troubleshooting with this deployment, I did not managed to figure out the fault, except that I had installed Cornie in that which is causing a conflict.

Synopsis:

  • syslog-ng was running and logging (installed, not a default).
  • crond was confirmed running (by rc-service crond status).
  • crontab entry was valid and present for root.
  • Ownership (chown), Mode (chmod) and UID, GID all are in favour of root in the Script, log and cron (cornie-service / crond)
  • crond was NOT sending any CRON messages to syslog-ng, even after explicit restarts
  • Installed and reinstalled Cornie, Deleted the .Pid files (/run/cronie.pid ; /var/run/cronie.pid)

I spun off another alpine (3.21, previous was the same) and became very surprised by this --

Here I didn't install Cornie, but no entry on the crontab which had a specific time mentioned, did work. For example if I wanted to run each day 12:30AM (30 12 * * * /path/to/script). However, when I put the schedule of running every minute (* * * * * /path/to/script) it ran properly. And I want to mention, that no declaration of path (PATH=) or Time zone / TZ (which was my primary suspicion) was provided, yet the each minute implementation was working. Furthermore I didnt even re-load the rc-services.

At this point I dont think there is any point going further, as most probably the busybox itself has some flaws or the cron has some other deep issues.

Improve this question
18
  • 2
    Please edit your question to include an example crontab entry that isn't working for you. Also, if you've created a simple test script that shows it has been invoked (e.g., creates a file under the home directory of the user whose crontab invoked it), showing that script's failing crontab entry would be very good. Commented Jun 21 at 15:47
  • 3
    That screenshot seems to show your intended script. What about the simple script that shows it was invoked, like the one I described in my previous comment? You're trying to troubleshoot a very basic and simple action: Cron invoking your script. So you want to begin with a very basic and simple script. After you've fixed the cron invocation, you can switch to your intended script, confident that cron will invoke it. (If there are further issues, you can then focus on the construction of the script) Commented Jun 21 at 18:11
  • 1
    Do: sudo zgrep -i cron /var/log/* Commented Jun 21 at 21:19
  • 1
    What does the script look like? Is it using any variables that you set in your interactive shell's startup files? Commented Jun 22 at 14:32
  • 1
    @Kusalananda My bad: it states 'My script calls $date' as I noted in a previous comment. It would be helpful to get responses and evidence from the comments already made. Commented Jun 22 at 14:38

3 Answers 3

Reset to default
2

cron runs your tasks with a seriously brief environment. It is pretty much HOME and SHELL (which is /bin/sh, whatever that is on your system). Cron does not log you in, so none of your profiles are read. You don't even get your own PATH. (I am slightly surprised that ~ works.)

This often leads to silent failures. It also means that "It runs from the command line" is irrelevant for diagnostic purposes.

I set up a task like:

*/5 * * * * { date; sleep 10; pwd; env; } >> /home/paul/myCronTest.log 2>&1

All I get from that is:

Sun 22 Jun 11:45:01 BST 2025
/home/paul
LANGUAGE=en_GB:en
HOME=/home/paul
LOGNAME=paul
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
LANG=en_GB.UTF-8
SHELL=/bin/sh
PWD=/home/paul

If your cron job produces any output that is not specifically redirected, it is likely to be sent to your Linux user mailbox (if any). It is strongly recommended that each cron task redirects any excess output to somewhere that you will find it. My /var/log/syslog just tells me:

(CRON) info (No MTA installed, discarding output)
Improve this answer
10
  • 1
    ~ is expanded to the value of the HOME variable by any POSIX-like shell, so the fact that ~ works in a crontab environment is not too strange (the command string in the 6th field of the schedule is executed by sh). Commented Jun 22 at 14:30
  • @Kusalananda Probably a throwback to some bad quoting I did 20 years ago. Alpine distro sh is BusyBox ash. I don't work blind like this: I set up a dry-run version of my task on a 5 or 10-minute schedule, and a tail -F on the debug log. Commented Jun 22 at 15:14
  • Hello, I am not quite getting the point, are you saying a direct path to the root is the problem ? And I should direct it to the user home? I want to mention, that my crontab entry is under root. Commented Jun 22 at 16:29
  • @Neail I believe root has two distinct ways to access cron. First is to set it up as for user root, which I believe is deprecated, but your crontab suggests this is what you have. Second is to set up a system-wide /etc/crontab, which adds a username to the crontab format. This allows cron to run tasks for any user, including system accounts like syslog, mail, uucp. I'm no sysadmin: See unix.stackexchange.com/questions/127732/… Commented Jun 23 at 8:35
  • 1
    @Paul_Pedant yes I will do when I will have the server on 24x7, as I dont want to implement anacron to complicate the matter further. The machine currently, is not running all the time constantly it will be hard to follow. I have thought to put the 'each once' schedule (as you mentioned) all together, one after another and will see which ticks, then we can have more insights. Commented Jun 24 at 10:29
1

Issue Resolved.

Updating the Answer with proven interference of cornie, however, I am also keeping the Timezone entry should someone need that.

Cornie

My Cornie was the culprit here and it was interfering.

I did just restore a snapshot of my alpine instance where I had installed Cornie but not altered the time zone, and here too, the clock time was not being called from the crontab. However, removing the Cornie, solved the issue. Use the command below. (it stops the cornie service, removes it from boot, removes the package)

 rc-service cronie stop && rc-update del cronie default && apk del cronie

then run -- rc-service crond restart

Thank you everyone for investing your time in it.

Just to mention , if you are experiencing similar issue please make sure

  1. You have provided the execute permission to your script, just do chmod +x /path/to/script after this many repetitions , I still keep forgetting this step.

  2. If you have updated time zones and yet cron not responding run rc-service crond restart

Timezone

Less probable cause was the Time zone change (I had the cornie installed earlier and all was causing by that)

Set the timezone properly with --

apk add tzdata

And created a sym-link (check for your region and fill the script below)

ln -sf /usr/share/zoneinfo/<Continent>/<Region> /etc/localtime

You must run this to make the new time zone get recognized by the system, only then the new time zone will work -- rc-service crond restart

Improve this answer
-3

The execution environments of your shell invoking a shell script and cron or a system service invoking a shell script differ, especially $PATH.

Look at the results of

echo "=== id ===";id
echo "=== set ===";set
echo "=== env ===";env | sort
echo "=== alias ===";alias

in each of your environments.

In system service invoked shell scripts (a secutity vulnerability, btw), use "absolute paths" for programs and other files. An "absolute path" is one that begins at /, e.g. /home/walt/bin/myprog, rather than just myprog.

Your $HOME directory is also different.

Improve this answer
2
  • Why would a user’s home directory be different when running a Cron job? Commented Jun 23 at 20:34
  • @waltinator Thank you for your response, yesterday I had added a new finding in the question, which clearly indicates that the env variables are not causing the error, depite the running cron, and accessible script there is a specific error in the cron when calling Timmed (of clock time) tasks. Additionally I have mentioned UID, GIDs are from the running user (root). Commented Jun 24 at 9:56

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.