Crons not working

On Debian mine have differnt permissions, cron directory is owned br root and permissions 755

Inside cron directory is:
Code: 
drwxr-xr-x 5 root   root    4096 Sep  9  2022 .
drwxr-xr-x 6 root   root    4096 Sep 10  2020 ..
drwxrwx--T 2 daemon daemon  4096 May 10 13:12 atjobs
drwxrwx--T 2 daemon daemon  4096 May 10 13:12 atspool
drwx-wx--T 2 root   crontab 4096 Nov  2 21:12 crontabs

And inside crontabs directory everything is 600 with owner of the user and group is crontab
 
this is from working clone of non working server, both has the same

1762180265538.png
 
Last edited:
can you direct edit crontab using
Code: 
crontab -e admin

and save without touch anything by type ":wq", the editor should be using same as vi editor.
 
Last edited:
Use the terminal / putty to re-save the crontab, it's just testing if direct edit can recovery or not.

Or after execute the "crontab -e admin", can you screenshort the current information ? We could look for the clue.

Don't edit via winscp or anything else, only "crontab" cli can done this job.
 
Ohm J said:
Use the terminal / putty to re-save the crontab, it's just testing if direct edit can recovery or not.

Or after execute the "crontab -e admin", can you screenshort the current information ? We could look for the clue.

Don't edit via winscp or anything else, only "crontab" cli can done this job.
Click to expand...
OK here you go:

login as: root
[email protected]'s password:
Last login: Mon Nov 3 16:11:22 2025 from 82.76.52.14
[root@host ~]# crontab -e admin
crontab: usage error: no arguments permitted after this option
Usage:
crontab [options] file
crontab [options]
crontab -n [hostname]

Options:
-u <user> define user
-e edit user's crontab
-l list user's crontab
-r delete user's crontab
-i prompt before deleting
-n <host> set host in cluster to run users' crontabs
-c get host in cluster to run users' crontabs
-T <file> test a crontab file syntax
-s selinux context
-V print version and exit
-x <mask> enable debugging

Default operation is replace, per 1003.2
[root@host ~]#
 
dorucrisan said:
Yes all crons are there.
Click to expand...
what do you mean that all crons are there? You can see the crons were running, but cannot see expected result?


dorucrisan said:
[root@host ~]# crontab -e admin
crontab: usage error: no arguments permitted after this option
Usage:
crontab [options] file
crontab [options]
crontab -n [hostname]
Click to expand...
crontab -e is enough. If you want to specify a cron for an user, you need -u
 
It's look good. I guest something relate to the site problem during night time.

this ensure to execute on the same as the cronjob, it's should help you debugging.
Code: 
sudo -u admin curl -v "https://url"
 
When trying to debug a cron job, you should really remove the “ > /dev/null 2>&1” that you have on all your cron jobs. What this will do is send you all the output via email. Otherwise, all the output and/or error messages get redirected to /dev/null and you will never know what happened to it. Once you have fixed everything, put them back so you don’t get inundated with emails for every cron job.
 
toml said:
When trying to debug a cron job, you should really remove the “ > /dev/null 2>&1” that you have on all your cron jobs. What this will do is send you all the output via email. Otherwise, all the output and/or error messages get redirected to /dev/null and you will never know what happened to it. Once you have fixed everything, put them back so you don’t get inundated with emails for every cron job.
Click to expand...
@ALL
1. There is no need to debug crons. All are fine and working on a clone server (I keep backup servers for emergencies). Besides, they worked for years exactly as they are now.
2. Server may return err500 when busy, that is the download server error, not mine. Even so, each cron has its own log file, it does not start automatically.
ONLY PROBLEM I HAVE IS THAT CRONS DOES NOT START AUTOMATICALLY AS SET IN DA CRON PAGE.
 
toml said:
When trying to debug a cron job, you should really remove the “ > /dev/null 2>&1” that you have on all your cron jobs. What this will do is send you all the output via email. Otherwise, all the output and/or error messages get redirected to /dev/null and you will never know what happened to it. Once you have fixed everything, put them back so you don’t get inundated with emails for every cron job.
Click to expand...
Yes I know that thank you.
 
So, hypothetically speaking, let’s say one of your shared libraries that wget in your case uses, was updated to an incompatible version. This would show you why, same thing if it were a permission problem. Just because it always worked is no reason to assume that something else on your system didn’t break.
 
You must log in or register to reply here.
Back
Top