SOLVED: Cron @reboot won't work on Debian Linux

[retnev]

I tried everything including your stickies.
None of the log files, and I scoured every possible logging target there is nowhere any errors reported regarding the @reboot items.
There are messages of my other non-@reboot cronjobs successfully run etc.

It just silently drops all @reboot as if it was intentionally accepted but deactivated in the sourcecode.

A simple cronjob created with only the following two lines (I made sure /root/LogfileForCrontabAtReboot.txt exists anyway beforehand)
@reboot touch /root/LogfileForCrontabAtReboot.txt
@reboot date >> /root/LogfileForCrontabAtReboot.txt

Does absolutely nothing on reboot. If I place regular * * * * * jobs in the file they execute perfectly so cron works. Just @reboot ignored.

I will have to look what fcron does and if it does maybe have a working @reboot, otherwhise I will have to fix the cron sources and fork it.

Cron seems abandoned in a very irresponsible way that WILL give linux a bad name.

[nixcraft]

@retnev

touch /root/LogfileForCrontabAtReboot.txt

I just tested your job at @reboot and rebooted my Debian box. It seems to be working fine.

As I said earlier, you are missing some steps or there is some other problem that you are not able to trace it out.

[retnev]

Which steps am I missing? Please point out your suggestions.
I install cron clean from scratch on a clean Debian stretch
I add the exact cronjob as you show above and check with “-l” that it is in fact loaded by cron which it is.
There are no steps I can leave out. That is how simple it is.
I reboot and everything works EXCEPT @reboot.
NOT working here.

Which version of Debian did you use and which version of Cron ?
That is crucial because as I reported, cron would support and then drop support for @reboot seemingly from version to version and what comes on debian version to version.
If I have your cron version I will install it and check to see if it works.
If it then works then it is my version of cron (which I strongly suspect as I had this garbage to deal with for the last 4 years since when they started fiddling with the @reboot support.

[retnev]

I filed another bugreport at debian. It is usually ignored. But I will keep trying. Honestly I cannot see what I can be doing rong.

I think it is the old 2011 bug again where Debian started cron at the wrong runlevel, which created @reboot to fail.
Any way you can check at which runlevel your cron is ran at reboot ?

Alternatively, just to check, how do I move crond to execute crontab as the last process before X is started ? My current runlevel is 5 with X running. I want to try this as it was a bug in 2011 with the same result I have now.

[PandaSpirit]

I will often add a delay to my @reboot scripts to be sure all necessary pieces are available, such as:
@reboot sleep 10; touch /root/LogfileForCrontabAtReboot.txt

[retnev]

Thank you for the reply.
Yes i tried that too in the past. It does not work for either /etc/rc.local or @reboot.this time. I installed a clean stretch again and still have the problem, definately the distro.
I will have to write an execute once at runlevel 5 script to replace all my @reboot entries until the cron or debian developers wakes up to this which will probably never happen.
I ampretty sure that debian executes cron at the wrong runlevel as they did on and off since 2011 when this problem started.

[nixcraft]

Also check if cron enabled in runlevel # 5 (gui)

systemctl list-dependencies graphical.target
systemctl list-dependencies .runlevel5.target 

For example:

for i in {0..6}
do
    echo "${i}"
    systemctl list-dependencies  runlevel${i}.target | grep cron
done

The above output indicate that cron is enabled in runlevels # 2,3,4, and 5. Delete all your custom job and try again. HTH.

[retnev]

Placing your code in a bash script deleteme, results
./deleteme
0
1
2
3
4
5
6

Go figure. NOTHING listed!
This is a vanilla debian install. I also installed completely different reruns of debian such as
MX and the same thing on both systems.
I dont understand why cron actually runs at all (it executes all lines except @reboot) , but if the output of your script is accurate, the @reboot WILL fail per the 2011 bug.

Thank you BTW, for the systemctl example it is helpful. About 6 years ago a wonderfool tool to set and alter runlevels for daemons, (cant remeber the exact name) was obsoleted and I could not bother to migrate to what must be systemd. Back then the new option was a nonsensical ball of garbage, but you seem to have found a use for it.

[nixcraft]

Enable cron service and reboot again as root

systemctl enable cron
systemctl start cron

HTH

[retnev]

$] systemctl enable cron
Synchronizing state of cron.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable cron
You have new mail in /var/mail/root

$] systemctl start cron
Failed to start cron.service: Unknown unit: cron.service
See system logs and ‘systemctl status cron.service’ for details.

But see…
$] ps -A |grep -i cron
6961 ? 00:00:00 cron

systemctl must be screwed up. It clearly runs.

This I actually did try already but I thought that systemctl is screwed up as cron IS definately running. It executes all in the crontabfile except @reboot entries, which is 100% understandable according to the 2011 bug that till this day is marked unresolved.

[nixcraft]

This is my last tip. LOL. Try deleting cron and all config. ALL COMMAND must run as root user

apt --purge remove cron

Reboot the box

reboot

Install cron

apt install cron
systemctl enable cron
systemctl restart cron

Now set up job for @reboot (again as root user):

crontab -e 

Append:

@reboot touch /root/test.file

Reboot the box:

for i in {0..6}
do
    echo "${i}"
    systemctl list-dependencies  runlevel${i}.target | grep cron
done
reboot

[retnev]

No need for you to answer, just a comment
Curious
Did everything up to including
systemctl restart cron
systemctl restart cron
Failed to restart cron.service: No such method ‘RestartUnit’
See system logs and ‘systemctl status cron.service’ for details*.
ps -A |grep -i cron
5045 ? 00:00:00 cron

I think I will rather uninstall cron again then reboot and see if cron still runs … if so, then it is a malicious issue.

[retnev]

Completed your suggestion.
Made sure cron completely removed.
Cron is running. Executed all but @reboot.

However, the most curious, still have

$] ./deleteme
0
1
2
3
4
5
6
$]

Where
$] cat deleteme
#!/bin/bash

for i in {0…6}
do
echo “${i}”
systemctl list-dependencies runlevel${i}.target | grep cron
done

exit

Still,
ps -A |grep -i cron
2287 ? 00:00:00 cron

Im starting to think the distros I am downloading are “special”

[retnev]

Clean install exactly like others from same disk, this time on laptop.
This time @reboot works but still
$] ./deleteme
0
1
2
3
4
5
6
$]
Seems like Cron is hardware dependent .
Absolutely ludicrous.

[retnev]

It seems your script doesnt work on MX18 which is debian stretch.

I downloaded the obsoleted chkconfig which I always used to do runlevels and luckily it still installed on Debian Stretch.
Why on earth they decided to obsolete chkconfig I dont understand. One hell of a nice tool.

Anyway
$] chkconfig --list | grep cron
anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off
cron 0:off 1:off 2:on 3:on 4:on 5:on 6:off

It seems the MX flavor Debian ships out of the box with BOTH anachron and chron running
ps -A |grep -i cron
1051 ? 00:00:00 cron
Sheesh !
However according to chkconfig cron runs in the correct levels.
So now I am really confused why it refused to run on particular machines only when installed from the same media.

[retnev]

Solved it. I must thank you (Nixcraft for the patient help)
Over the years I found you to be the most knowledgeable and kind Unix guru on the web.

Here is what I found what happened.

The MX18 Distro by default seemingly installs both anacron and cron and starts BOTH of them. Sheesh !

$] chkconfig --list | grep cron
anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off
cron 0:off 1:off 2:on 3:on 4:on 5:on 6:off

So I continued to completely remove anacron. You cant have two cron daemons running

$] apt remove anacron
Reading package lists… Done
Building dependency tree
Reading state information… Done
Package ‘anacron’ is not installed, so not removed.
0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.

Go figure … it is not installed but it is running on my system. How the hell can that be … ?
So I proceeded to completely purge anacron from the system, and lo and behold, there were an installation present that did not register with apt ! and this was a CLEAN MX18 install. !!!

$] dpkg --purge anacron
(Reading database … 453474 files and directories currently installed.)
Purging configuration files for anacron (2.3-24) …
Processing triggers for systemd (232-25+deb9u8) …
You have new mail in /var/mail/root

Since anacron was still running I tried to stop it with service anacon stop, but that didnt stop it either.
So since I now completely purged the zombie anacron garbage that came default with MX18, I rebooted.

Upon reboot, I found that now anacron is gone

$]chkconfig --list |grep -i cron
cron 0:off 1:off 2:on 3:on 4:on 5:on 6:off

And suddenly I have that all the @reboot started to work as it created the testfiles in my root directory.

I am pretty baffled how this happens. Using the EXACT same MX18 install media now on 4 computers, 3 of them have both anacron and cron running, but one, the laptop dont have anacron running and only cron. Seemingly the anacron bogus install is triggered by hardware.
I tested some of my Debian stretch installations and some of them has exactly the same problem. So MX18 inherits this straight from Debian Stretch. It is obviously a BUG that is somehow triggered to activate anacron in conjuction with cron. The creepy part to me is why systemctl is basically deactivated at the same time for cron processes so you cannot see runlevels. THAT looks malicious. This all happens on CLEAN installs on 4 different machines from the SAME installation disk.

Anyway, this is solved if you purge anacron. Just an uninstall is not going to help.

[retnev]

To add:

On the laptop that was installed clean from MX18 but did execute reboot I got
ps -A |grep -i cron
1051 ? 00:00:00 cron
So no anacron
But suddenly your script works, where it wouldnt on the other 3 where anacron was running together with cron. It shows anacron present.

$] ./deleteme
“0”
“1”
“2”
● ├─anacron.service
● ├─cron.service
● │ ├─anacron.timer
“3”
● ├─anacron.service
● ├─cron.service
● │ ├─anacron.timer
“4”
● ├─anacron.service
● ├─cron.service
● │ ├─anacron.timer
“5”
● ├─anacron.service
● ├─cron.service
● │ ├─anacron.timer
“6”

Also
$]chkconfig --list |grep -i cron
anacron 0:off 1:off 2:on 3:on 4:on 5:on 6:off
cron 0:off 1:off 2:on 3:on 4:on 5:on 6:off

But, what is different is that anacron is not actively running allthough runlevels are set.
$]ps -A |grep -i cron
1051 ? 00:00:00 cron

So the question remains, why did anacron appear as a running daemon together with cron on three of the other computers but not on the laptop from the same install disk. Clearly hardware triggered.!

Removed anacron completely and all still works well.

[retnev]

Summary

To summarize for anyone having the same problem with Debian and possibly other distros
Check if both cron and anacron runs.

If both runs as below, I found the @reboot in the crontabfile will not execute.
ps-A |grep -i cron
1049 ? 00:00:00 anacron
1052 ? 00:00:00 cron

Only cron should run.

Also check runlevels with

chkconfig --list |grep -i cron
or
sysv-rc-conf --list |grep -i cron

There must be no mention of anacron

To get rid of anacron will mean you will loose gnome scheduler or whatever it is called. I never had use for it and I have a hunch that it is scheduler that installs anacron without regard for cron and breaks it.

To get rid of anacron
dmesg --purge anacron

then reboot and do the steps again until only cron runs as daemon.

I found that this solved both my /etc/resolv.conf and @reboot not working.

[nixcraft]

Glad it worked out for you.

[retnev]

Update, this cron anacron mess seems to be the work of systemd. Systemd in my opinion is most irresponsible. Not a sysadmins friend.