What's new

Crontab jobs disappeared.

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I'm wondering if it's Diversion's multiple (repeated) calls to restart dnsmasq. Optional dnsmasq settings are "off" in Diversion's settings.

*EDIT*
Optional dnsmasq settings are actually turned "on" in Diversion.
 
Last edited:
I'm wondering if it's Diversion's multiple (repeated) calls to restart dnsmasq
I started this thread when I saw most of my cronjobs disappear, but I don't run Diversion.

But, I have a strong suspicion that the disappearance was associated with a restart_firewall event which includes a restart_dnsmasq.
 
I am leaning toward a concurrency problem (agreeing with @dave14305). I see me implementing @SomeWhereOverTheRainBow solution in the near future. I have not had an issue yet, but why wait.
 
We need a smoking gun on this.
I'm leaning towards @dave14305's observation now. It certainly makes sense, along with the weight of experience behind it.
Jynx @Jeffrey Young
 
OK, I had a quick try of @SomeWhereOverTheRainBow cru replacement and it "Failed to acquire lock" after the first cru add.

I tried running my init-start script which contains the following...
Code:
#!/bin/sh
#
# Add our scripts to cron job list.
#
cru a AGTxEM "15 3 * * * /jffs/AGT/scripts/regular-email"
cru a AGTxEU "3 4 * * * wl -i eth5 deauthenticate 8C:85:80:54:82:28"
cru a AGTxMQ "*/5 * * * * /jffs/AGT/scripts/send-cputemp-mqtt"
cru a AGTxBU "13 2 * * * /jffs/AGT/scripts/BackupToNAS.sh"

and this is what happened...

Code:
07-Mar 16:05:10 AX cru[4953]: Calling PID: 15454, CMD: -sh
07-Mar 16:06:08 AX cru[5284]: Args: a AGTxEM 15 3 * * * /jffs/AGT/scripts/regular-email
07-Mar 16:06:08 AX cru[5284]: Calling PID: 5283, CMD: /bin/sh./init-start
07-Mar 16:06:38 AX cru[5284]: Failed to acquire lock
07-Mar 16:06:38 AX cru[5528]: Args: a AGTxEU 3 4 * * * wl -i eth5 deauthenticate EufyDoorBell
07-Mar 16:06:38 AX cru[5528]: Calling PID: 5283, CMD: /bin/sh./init-start
07-Mar 16:07:09 AX cru[5528]: Failed to acquire lock
07-Mar 16:07:09 AX cru[5810]: Args: a AGTxMQ */5 * * * * /jffs/AGT/scripts/send-cputemp-mqtt
07-Mar 16:07:09 AX cru[5810]: Calling PID: 5283, CMD: /bin/sh./init-start
07-Mar 16:07:38 AX cru[5810]: Failed to acquire lock
07-Mar 16:07:38 AX cru[6059]: Args: a AGTxBU 13 2 * * * /jffs/AGT/scripts/BackupToNAS.sh
07-Mar 16:07:38 AX cru[6059]: Calling PID: 5283, CMD: /bin/sh./init-start
07-Mar 16:08:09 AX cru[6059]: Failed to acquire lock
 
OK, I read thru the script and found that the file "/var/lock/cron.lock" already existed.
Once I deleted it, the script now works.
[ BUT - how did that file get there??? ]
 
Strange, /var/lock/cron.lock exists for me too. Stranger, I've never run @SomeWhereOverTheRainBow's modified script - I've always used Dave's.
 
No sorry, it still doesn't work, now crond is failing
@SomeWhereOverTheRainBow : any ideas, I'm not a great writer of scripts!!!


Code:
07-Mar 16:31:00 AX crond[1561]: user RT-AC86U-admin: parse error at TxEM
07-Mar 16:31:00 AX crond[1561]: user RT-AC86U-admin: parse error at TxEU
07-Mar 16:31:00 AX crond[1561]: user RT-AC86U-admin: parse error at TxMQ
07-Mar 16:31:00 AX crond[1561]: user RT-AC86U-admin: parse error at TxBU

the crontab file seems to be getting trashed ....

Code:
cru l
51 21 */7 * * service restart_letsencrypt #LetsEncrypt#
*/2 * * * * /etc/openvpn/server1/vpn-watchdog1.sh #CheckVPNServer1#
TxEM 15 3 * * * /jffs/AGT/scripts/regular-email #AGTxEM#
TxEU 3 4 * * * wl -i eth5 deauthenticate 8C:85:80:54:82:28 #AGTxEU#
TxMQ */5 * * * * /jffs/AGT/scripts/send-cputemp-mqtt #AGTxMQ#
TxBU 13 2 * * * /jffs/AGT/scripts/BackupToNAS.sh #AGTxBU#
 
This is about to get interesting!

1709830402817.png
 
Strange, /var/lock/cron.lock exists for me too. Stranger, I've never run @SomeWhereOverTheRainBow's modified script - I've always used Dave's.
/var/lock/cron.lock is part of the normal cru script. It should always be there apart from a very brief moment when the crontab is being updated.

I think a proper locking should use flock.
Indeed. I really can't guess what the writer of that script intended. It's like they started to write a locking mechanism and then gave up.

EDIT: Looking at it a bit more I sort of see what they're getting at. But it doesn't strike me as a reliable "locking" mechanism. It looks like something that would work OK most of the time. As Dave said, to do it properly it should be using flock, and if it can't get an exclusive lock then exit rather than carrying on.
 
Last edited:
This version is without logging
You're right. I just saw the log without checking the times. Would love to have the logging back though - may help later.
 
No sorry, it still doesn't work, now crond is failing
@SomeWhereOverTheRainBow : any ideas, I'm not a great writer of scripts!!!


Code:
07-Mar 16:31:00 AX crond[1561]: user RT-AC86U-admin: parse error at TxEM
07-Mar 16:31:00 AX crond[1561]: user RT-AC86U-admin: parse error at TxEU
07-Mar 16:31:00 AX crond[1561]: user RT-AC86U-admin: parse error at TxMQ
07-Mar 16:31:00 AX crond[1561]: user RT-AC86U-admin: parse error at TxBU

the crontab file seems to be getting trashed ....

Code:
cru l
51 21 */7 * * service restart_letsencrypt #LetsEncrypt#
*/2 * * * * /etc/openvpn/server1/vpn-watchdog1.sh #CheckVPNServer1#
TxEM 15 3 * * * /jffs/AGT/scripts/regular-email #AGTxEM#
TxEU 3 4 * * * wl -i eth5 deauthenticate 8C:85:80:54:82:28 #AGTxEU#
TxMQ */5 * * * * /jffs/AGT/scripts/send-cputemp-mqtt #AGTxMQ#
TxBU 13 2 * * * /jffs/AGT/scripts/BackupToNAS.sh #AGTxBU#
Haha, you wait this long to try something. I almost forgot about it.
 
OK, I read thru the script and found that the file "/var/lock/cron.lock" already existed.
Once I deleted it, the script now works.
[ BUT - how did that file get there??? ]
Alan you have to make sure you are using the script correctly.

it removes the lock file at the end of the each run.

Code:
    elif [ "$1" = "unlock" ]; then
        rm -f "$lock_file"
    fi

that means you had other concurrent cronjobs running that had not yet completed before those jobs were attempting to run.

Also make sure you make a seperate script for your init-start since init-start is considered a "blocking" script.

eg.

mycron.sh
Code:
#!/bin/sh
#
# Add our scripts to cron job list.
#
cru a AGTxEM "15 3 * * * /jffs/AGT/scripts/regular-email"
cru a AGTxEU "3 4 * * * wl -i eth5 deauthenticate 8C:85:80:54:82:28"
cru a AGTxMQ "*/5 * * * * /jffs/AGT/scripts/send-cputemp-mqtt"
cru a AGTxBU "13 2 * * * /jffs/AGT/scripts/BackupToNAS.sh"

then invoke it from init-start like this:-

Code:
#!/bin/sh
#
#
sh /jffs/scripts/mycron.sh &

But like @dave14305 says flock should be better to use. You don't have to worry about what happens to the lock file and the command will just wait until the other completes.
 
Last edited:
I think a proper locking should use flock. Can’t test this since my router is being RMA’d, so if any brave volunteers step forward, let me know if it runs.
I combined logging and locking in the original version with instructions here:
 
I combined logging and locking in the original version with instructions here:
Looks great, that should definitely do the job. Hopefully everyone who invokes all these individual cronjobs realize it is better to do it from a separate shell script that runs in the background, than to try to invoke them as individual lines inside the main calling script itself (alternatively they can be invoked in a separate shell in the main calling script similar to this format) &.
 
Last edited:
Looks great, that should definitely do the job. Hopefully everyone who invokes all these individual cronjobs realize it is better to do it from a separate shell script that runs in the background, than to try to invoke them as individual lines inside the main calling script itself (alternatively they can be invoked in a separate shell in the main calling script) &.
I think the problem is with the cru command, not the scripts that are being scheduled.
 

Similar threads

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top