Hi all,
I am having strange problems with my cron jobs in my CentOS7 kvm host. After the initial install and first boot, any cron job configured had run (including cron tasks installed by some rpm packages).
Last cron's entry log is:
Oct 9 17:01:01 santgraal CROND[9014]: (root) CMD (run-parts /etc/cron.hourly) Oct 9 17:01:01 santgraal run-parts(/etc/cron.hourly)[9014]: starting 0anacron Oct 9 17:01:01 santgraal run-parts(/etc/cron.hourly)[9023]: finished 0anacron Oct 9 17:01:01 santgraal run-parts(/etc/cron.hourly)[9014]: starting 0yum-hourly.cron Oct 9 17:01:01 santgraal run-parts(/etc/cron.hourly)[9029]: finished 0yum-hourly.cron
cron service is running without problems:
[root@coskvm01 log]# systemctl status crond crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled) Active: active (running) since Sun 2015-10-11 11:49:41 UTC; 28min ago Main PID: 5124 (crond) CGroup: /system.slice/crond.service └─5124 /usr/sbin/crond -n
Forcing to run cron tasks editing root's crontab with "crontab -e", it doesn't works also.
Is this a bug?? Or do I need to install some package apart of:
cronie-1.4.11-13.el7.x86_64 cronie-anacron-1.4.11-13.el7.x86_64 crontabs-1.11-6.20121102git.el7.noarch ???
On Oct 11, 2015, at 8:20 AM, C. L. Martinez carlopmart@gmail.com wrote:
I am having strange problems with my cron jobs in my CentOS7 kvm host. After the initial install and first boot, any cron job configured had run (including cron tasks installed by some rpm packages).
Did you have a question or error to point out? So far all I see is a correctly-running system.
-- Jonathan Billings billings@negate.org
On Sunday, October 11, 2015, Jonathan Billings billings@negate.org wrote:
On Oct 11, 2015, at 8:20 AM, C. L. Martinez <carlopmart@gmail.com javascript:;> wrote:
I am having strange problems with my cron jobs in my CentOS7 kvm host. After the initial install and first boot, any cron job configured had run (including cron tasks installed by some rpm packages).
Did you have a question or error to point out? So far all I see is a correctly-running system.
-- Jonathan Billings <billings@negate.org javascript:;>
That's the problem. There is no error but any cron job configured runs.. And this is the cuestion: why any cron job works?.
CentOS mailing list CentOS@centos.org javascript:; https://lists.centos.org/mailman/listinfo/centos
On 10/11/2015 09:38 AM, C. L. Martinez wrote:
That's the problem. There is no error but any cron job configured runs.. And this is the cuestion: why any cron job works?.
It's not clear what you're asking. It would help if you replied with an example of a specific job that's configured on your system, and explaining what it is doing that it should not, or what it is not doing that it should.
On Mon, Oct 12, 2015 at 12:15 AM, Gordon Messmer gordon.messmer@gmail.com wrote:
On 10/11/2015 09:38 AM, C. L. Martinez wrote:
That's the problem. There is no error but any cron job configured runs.. And this is the cuestion: why any cron job works?.
It's not clear what you're asking. It would help if you replied with an example of a specific job that's configured on your system, and explaining what it is doing that it should not, or what it is not doing that it should.
For example: logwatch. Logwatch sends a daily email report about system's health. I didn't received this email from October 9th ... and email configuration is ok.
On Tue, Oct 13, 2015 at 06:24:19AM +0000, C. L. Martinez wrote:
For example: logwatch. Logwatch sends a daily email report about system's health. I didn't received this email from October 9th ... and email configuration is ok.
So your problem is that cron jobs *DO NOT* run? Because every message you've sent so far has said that all jobs run.
On Tue, Oct 13, 2015 at 1:39 PM, Jonathan Billings billings@negate.org wrote:
On Tue, Oct 13, 2015 at 06:24:19AM +0000, C. L. Martinez wrote:
For example: logwatch. Logwatch sends a daily email report about system's health. I didn't received this email from October 9th ... and email configuration is ok.
So your problem is that cron jobs *DO NOT* run?
Yes. that is the problem ... Sorry If I am not explained very well.
Date: Tuesday, October 13, 2015 13:41:56 +0000 From: "C. L. Martinez" carlopmart@gmail.com
On Tue, Oct 13, 2015 at 1:39 PM, Jonathan Billings billings@negate.org wrote:
On Tue, Oct 13, 2015 at 06:24:19AM +0000, C. L. Martinez wrote:
For example: logwatch. Logwatch sends a daily email report about system's health. I didn't received this email from October 9th ... and email configuration is ok.
So your problem is that cron jobs *DO NOT* run?
Yes. that is the problem ... Sorry If I am not explained very well.
What does /var/log/cron show? Are the jobs triggered, but you don't get the expected output, or not triggered?
If not triggered, you might want to show your crontab entries.
On Tue, Oct 13, 2015 at 1:45 PM, Richard lists-centos@listmail.innovate.net wrote:
Date: Tuesday, October 13, 2015 13:41:56 +0000 From: "C. L. Martinez" carlopmart@gmail.com
On Tue, Oct 13, 2015 at 1:39 PM, Jonathan Billings billings@negate.org wrote:
On Tue, Oct 13, 2015 at 06:24:19AM +0000, C. L. Martinez wrote:
For example: logwatch. Logwatch sends a daily email report about system's health. I didn't received this email from October 9th ... and email configuration is ok.
So your problem is that cron jobs *DO NOT* run?
Yes. that is the problem ... Sorry If I am not explained very well.
What does /var/log/cron show?
Nothing ... It is empty.
Are the jobs triggered, but you don't
get the expected output, or not triggered?
They are not triggered ...
If not triggered, you might want to show your crontab entries.
I haven't entries in conrtab's users file at this moment, but I have done a test: * * * * * ls -la, and it is not triggered. But like I say before, installed system cronjobs like logwatch task are not triggered ...
Date: Tuesday, October 13, 2015 13:54:28 +0000 From: "C. L. Martinez" carlopmart@gmail.com
On Tue, Oct 13, 2015 at 1:45 PM, Richard lists-centos@listmail.innovate.net wrote:
Date: Tuesday, October 13, 2015 13:41:56 +0000 From: "C. L. Martinez" carlopmart@gmail.com
On Tue, Oct 13, 2015 at 1:39 PM, Jonathan Billings billings@negate.org wrote:
On Tue, Oct 13, 2015 at 06:24:19AM +0000, C. L. Martinez wrote:
For example: logwatch. Logwatch sends a daily email report about system's health. I didn't received this email from October 9th ... and email configuration is ok.
So your problem is that cron jobs *DO NOT* run?
Yes. that is the problem ... Sorry If I am not explained very well.
What does /var/log/cron show?
Nothing ... It is empty.
Are the jobs triggered, but you don't
get the expected output, or not triggered?
They are not triggered ...
If not triggered, you might want to show your crontab entries.
I haven't entries in conrtab's users file at this moment, but I have done a test: * * * * * ls -la, and it is not triggered. But like I say before, installed system cronjobs like logwatch task are not triggered ...
What is returned if you issue the command:
ps auxw | grep cron | grep -v grep
On Tue, Oct 13, 2015 at 1:58 PM, Richard lists-centos@listmail.innovate.net wrote:
Date: Tuesday, October 13, 2015 13:54:28 +0000 From: "C. L. Martinez" carlopmart@gmail.com
On Tue, Oct 13, 2015 at 1:45 PM, Richard lists-centos@listmail.innovate.net wrote:
Date: Tuesday, October 13, 2015 13:41:56 +0000 From: "C. L. Martinez" carlopmart@gmail.com
On Tue, Oct 13, 2015 at 1:39 PM, Jonathan Billings billings@negate.org wrote:
On Tue, Oct 13, 2015 at 06:24:19AM +0000, C. L. Martinez wrote:
For example: logwatch. Logwatch sends a daily email report about system's health. I didn't received this email from October 9th ... and email configuration is ok.
So your problem is that cron jobs *DO NOT* run?
Yes. that is the problem ... Sorry If I am not explained very well.
What does /var/log/cron show?
Nothing ... It is empty.
Are the jobs triggered, but you don't
get the expected output, or not triggered?
They are not triggered ...
If not triggered, you might want to show your crontab entries.
I haven't entries in conrtab's users file at this moment, but I have done a test: * * * * * ls -la, and it is not triggered. But like I say before, installed system cronjobs like logwatch task are not triggered ...
What is returned if you issue the command:
ps auxw | grep cron | grep -v grep
Cron service is running:
root 607 0.0 0.0 126304 1580 ? Ss 05:33 0:00 /usr/sbin/crond -n
And according to systemd, without problems:
crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled) Active: active (running) since Tue 2015-10-13 05:33:28 UTC; 8h ago Main PID: 607 (crond) CGroup: /system.slice/crond.service └─607 /usr/sbin/crond -n
On Tue, Oct 13, 2015 at 02:04:49PM +0000, C. L. Martinez wrote:
And according to systemd, without problems:
crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled) Active: active (running) since Tue 2015-10-13 05:33:28 UTC; 8h ago Main PID: 607 (crond) CGroup: /system.slice/crond.service └─607 /usr/sbin/crond -n
Do you see anything helpful in the journal?
run 'journalctl _SYSTEMD_UNIT=crond.service'
On Tue, Oct 13, 2015 at 2:35 PM, Jonathan Billings billings@negate.org wrote:
On Tue, Oct 13, 2015 at 02:04:49PM +0000, C. L. Martinez wrote:
And according to systemd, without problems:
crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled) Active: active (running) since Tue 2015-10-13 05:33:28 UTC; 8h ago Main PID: 607 (crond) CGroup: /system.slice/crond.service └─607 /usr/sbin/crond -n
Do you see anything helpful in the journal?
run 'journalctl _SYSTEMD_UNIT=crond.service'
Nop, because binary logs (using journalctl) are disabled in this host ... But under /var/log/messages, there is no error ...
John Hodrien wrote:
On Tue, 13 Oct 2015, C. L. Martinez wrote:
Nop, because binary logs (using journalctl) are disabled in this host ... But under /var/log/messages, there is no error ...
Might it be an idea to *not* disable logging?
More to the point, perhaps, is there any way of recovering the entries that used to be in /var/log/ eg maillog? Does "journalctl -u sendmail" give exactly the same information? And what exactly is the status of syslog now?
On Tue, Oct 13, 2015 at 02:39:24PM +0000, C. L. Martinez wrote:
Nop, because binary logs (using journalctl) are disabled in this host ... But under /var/log/messages, there is no error ...
How did you disable journald?
On 10/13/2015 02:59 PM, Jonathan Billings wrote:
On Tue, Oct 13, 2015 at 02:39:24PM +0000, C. L. Martinez wrote:
Nop, because binary logs (using journalctl) are disabled in this host ... But under /var/log/messages, there is no error ...
How did you disable journald?
Changing Storage's option under /etc/systemd/journald.conf to none.
On Wed, Oct 14, 2015 at 09:24:00AM +0000, C.L. Martinez wrote:
On 10/13/2015 02:59 PM, Jonathan Billings wrote:
How did you disable journald?
Changing Storage's option under /etc/systemd/journald.conf to none.
While Storage=none is supposed to forward on messages to syslog, it might be worth checking to see what process owns /dev/log: # lsof /dev/log
On 10/14/2015 01:56 PM, Jonathan Billings wrote:
lsof /dev/log
Uhmm ... that is not what I expect:
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 27u unix 0xffff880250ea0f00 0t0 1436 /dev/log systemd-j 263 root 5u unix 0xffff880250ea0f00 0t0 1436 /dev/log
In theory, rsyslog is listenning to uxsock and imjournal:
# rsyslog configuration file
# For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html # If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html
#### MODULES ####
# The imjournal module bellow is now used as a message source instead of imuxsock. $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $ModLoad imjournal # provides access to the systemd journal #$ModLoad imklog # reads kernel messages (the same are read from journald) #$ModLoad immark # provides --MARK-- message capability
On 10/14/2015 07:09 AM, C.L. Martinez wrote:
Uhmm ... that is not what I expect:
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 27u unix 0xffff880250ea0f00 0t0 1436 /dev/log systemd-j 263 root 5u unix 0xffff880250ea0f00 0t0 1436 /dev/log
So, the obvious next step is to make sure journald isn't holding that socket. That's outside my experience, but I'd imagine that you can:
systemctl disable systemd-journald.service systemctl stop systemd-journald.service
Then you'll need to restart rsyslog and verify that it owns /dev/log.
In theory, rsyslog is listenning to uxsock and imjournal:
Only one process can have a socket open at a time. Since journald holds /dev/log, rsyslog can't, which is why your cron log is empty.
#### MODULES #### # The imjournal module bellow is now used as a message source instead of imuxsock. $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $ModLoad imjournal # provides access to the systemd journal
There's no real point in using imjournal if journald isn't running.
On 10/14/2015 06:42 PM, Gordon Messmer wrote:
On 10/14/2015 07:09 AM, C.L. Martinez wrote:
Uhmm ... that is not what I expect:
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 27u unix 0xffff880250ea0f00 0t0 1436 /dev/log systemd-j 263 root 5u unix 0xffff880250ea0f00 0t0 1436 /dev/log
So, the obvious next step is to make sure journald isn't holding that socket. That's outside my experience, but I'd imagine that you can:
systemctl disable systemd-journald.service systemctl stop systemd-journald.service
Then you'll need to restart rsyslog and verify that it owns /dev/log.
In theory, rsyslog is listenning to uxsock and imjournal:
Only one process can have a socket open at a time. Since journald holds /dev/log, rsyslog can't, which is why your cron log is empty.
#### MODULES #### # The imjournal module bellow is now used as a message source instead of imuxsock. $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $ModLoad imjournal # provides access to the systemd journal
There's no real point in using imjournal if journald isn't running.
Hi,
First of all, sorry for this later response. I was very busy last days.
Ok, I have solved this problem partially. First, I have changed under journald.conf file Storage=volatile instead of Storage=none. After doing that, logs returned but there is no error under cron.log about cronjobs, system's jobs included. But they are not triggered.
I have removed cronie-anacron package and I have installed cronie-noanacron and voilà!! ... all works ok: system cronjobs and my configured jobs ...
I am not sure if it is a bug or some type of misconfiguration ... But I have two Oracle Linux 7.x LXC servers using cronie-anacron package to trigger cronjobs, and works without problems.
Thoughts??
On 10/19/2015 04:49 AM, C.L. Martinez wrote:
Ok, I have solved this problem partially. First, I have changed under journald.conf file Storage=volatile instead of Storage=none. After doing that, logs returned but there is no error under cron.log about cronjobs, system's jobs included. But they are not triggered.
What does "included" mean? If the cron jobs are recorded in the log, then they were triggered. If they are recorded and not doing something that you expect, please describe what you expected to happen that did not.
I have removed cronie-anacron package and I have installed cronie-noanacron and voilà!! ... all works ok: system cronjobs and my configured jobs ...
It's possible that something was broken with anacron? It's hard to diagnose further after you removed the package. Reinstalling it would probably fix whatever was broken. If you put that package back and removed cronie-noanacron, and if the problem came back, you could troubleshoot further, but I wouldn't expect that to happen.
I am not sure if it is a bug or some type of misconfiguration ... But I have two Oracle Linux 7.x LXC servers using cronie-anacron package to trigger cronjobs, and works without problems.
Probably misconfiguration.
On 10/13/2015 07:39 AM, C. L. Martinez wrote:
Nop, because binary logs (using journalctl) are disabled in this host ... But under /var/log/messages, there is no error ...
If you haven't reconfigured rsyslogd to use the uxsock source, disabling the journal will also disable the legacy logging system. If your cron log is actually empty, then you probably aren't getting any logs at all.
Start by turning your logging system back on. It's the best source of data that you have at this point.
On 10/13/2015 05:38 PM, Gordon Messmer wrote:
On 10/13/2015 07:39 AM, C. L. Martinez wrote:
Nop, because binary logs (using journalctl) are disabled in this host ... But under /var/log/messages, there is no error ...
If you haven't reconfigured rsyslogd to use the uxsock source, disabling the journal will also disable the legacy logging system. If your cron log is actually empty, then you probably aren't getting any logs at all.
Start by turning your logging system back on. It's the best source of data that you have at this point.
Correct Gordon, but I have enabled uxsock under rsyslog.conf to avoid the situation that you have explained.
Thanks.
Please note that /etc/cron.* files use a bit different syntax as normal crontab entries. First entry is user-id for cron job. It also requires strict permissions like (rw,r,r)
Eero
2015-10-13 17:39 GMT+03:00 C. L. Martinez carlopmart@gmail.com:
On Tue, Oct 13, 2015 at 2:35 PM, Jonathan Billings billings@negate.org wrote:
On Tue, Oct 13, 2015 at 02:04:49PM +0000, C. L. Martinez wrote:
And according to systemd, without problems:
crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled) Active: active (running) since Tue 2015-10-13 05:33:28 UTC; 8h ago Main PID: 607 (crond) CGroup: /system.slice/crond.service └─607 /usr/sbin/crond -n
Do you see anything helpful in the journal?
run 'journalctl _SYSTEMD_UNIT=crond.service'
Nop, because binary logs (using journalctl) are disabled in this host ... But under /var/log/messages, there is no error ... _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Date: Tuesday, October 13, 2015 13:54:28 +0000 From: "C. L. Martinez" carlopmart@gmail.com
On Tue, Oct 13, 2015 at 1:45 PM, Richard lists-centos@listmail.innovate.net wrote:
Date: Tuesday, October 13, 2015 13:41:56 +0000 From: "C. L. Martinez" carlopmart@gmail.com
On Tue, Oct 13, 2015 at 1:39 PM, Jonathan Billings billings@negate.org wrote:
On Tue, Oct 13, 2015 at 06:24:19AM +0000, C. L. Martinez wrote:
For example: logwatch. Logwatch sends a daily email report about system's health. I didn't received this email from October 9th ... and email configuration is ok.
So your problem is that cron jobs *DO NOT* run?
Yes. that is the problem ... Sorry If I am not explained very well.
What does /var/log/cron show?
Nothing ... It is empty.
Are the jobs triggered, but you don't
get the expected output, or not triggered?
They are not triggered ...
If not triggered, you might want to show your crontab entries.
I haven't entries in conrtab's users file at this moment, but I have done a test: * * * * * ls -la, and it is not triggered. But like I say before, installed system cronjobs like logwatch task are not triggered ...
What is returned when you issue the commands:
ps auxw | grep cron | grep -v grep
systemctl status crond.service
On Tue, Oct 13, 2015 at 02:05:47PM +0000, Richard wrote:
If not triggered, you might want to show your crontab entries.
I haven't entries in conrtab's users file at this moment, but I have done a test: * * * * * ls -la, and it is not triggered. But like I say before, installed system cronjobs like logwatch task are not triggered ...
What is returned when you issue the commands:
ps auxw | grep cron | grep -v grep
Do you have spamassassin running on the machine? I remember at one point, it was tagging the daily log messages as spam--this was awhile ago, I don't remember the details or even if I fixed it or it was fixed by an update.
On Tue, Oct 13, 2015 at 2:11 PM, Scott Robbins scottro11@gmail.com wrote:
On Tue, Oct 13, 2015 at 02:05:47PM +0000, Richard wrote:
If not triggered, you might want to show your crontab entries.
I haven't entries in conrtab's users file at this moment, but I have done a test: * * * * * ls -la, and it is not triggered. But like I say before, installed system cronjobs like logwatch task are not triggered ...
What is returned when you issue the commands:
ps auxw | grep cron | grep -v grep
Do you have spamassassin running on the machine? I remember at one point, it was tagging the daily log messages as spam--this was awhile ago, I don't remember the details or even if I fixed it or it was fixed by an update.
No, it acts as a KVM server ...
On 10/13/2015 09:54 AM, C. L. Martinez wrote:
I haven't entries in conrtab's users file at this moment, but I have done a test: * * * * * ls -la, and it is not triggered. But like I say before, installed system cronjobs like logwatch task are not triggered ... _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I'd say that crontab doesn't actually prove that the job isn't being triggered, it just proves there's an email config/sending/something problem.
if you change that to to something like
* * * * * touch /var/tmp/cron-test-file
does it create and keep changing the date on the file?
zep wrote:
On 10/13/2015 09:54 AM, C. L. Martinez wrote:
I haven't entries in conrtab's users file at this moment, but I have done a test: * * * * * ls -la, and it is not triggered. But like I say before, installed system cronjobs like logwatch task are not triggered
I'd say that crontab doesn't actually prove that the job isn't being triggered, it just proves there's an email config/sending/something problem.
if you change that to to something like
- touch /var/tmp/cron-test-file
does it create and keep changing the date on the file?
Dumb question: is there anything in /etc/cron.*?
mark
On 10/13/2015 05:49 PM, m.roth@5-cent.us wrote:
zep wrote:
On 10/13/2015 09:54 AM, C. L. Martinez wrote:
I haven't entries in conrtab's users file at this moment, but I have done a test: * * * * * ls -la, and it is not triggered. But like I say before, installed system cronjobs like logwatch task are not triggered
I'd say that crontab doesn't actually prove that the job isn't being triggered, it just proves there's an email config/sending/something problem.
if you change that to to something like
- touch /var/tmp/cron-test-file
does it create and keep changing the date on the file?
Dumb question: is there anything in /etc/cron.*?
mark
Yes:
-rw------- 1 root root 0 Jul 27 10:57 /etc/cron.deny -rw-r--r--. 1 root root 451 Jun 9 2014 /etc/crontab
/etc/cron.d: total 28 drwxr-xr-x. 2 root root 72 Sep 25 09:10 . drwxr-xr-x. 115 root root 8192 Oct 14 09:19 .. -rw-r--r-- 1 root root 128 Jul 27 10:57 0hourly -rw-r--r-- 1 root root 108 Mar 6 2015 raid-check -rw------- 1 root root 235 Mar 6 2015 sysstat -rw-r--r-- 1 root root 187 Jan 27 2014 unbound-anchor
/etc/cron.daily: total 40 drwxr-xr-x. 2 root root 98 Sep 25 09:11 . drwxr-xr-x. 115 root root 8192 Oct 14 09:19 .. -rwxr-xr-x. 1 root root 434 Jun 10 2014 0logwatch -rwxr-xr-x. 1 root root 332 Mar 9 2015 0yum-daily.cron -rwx------. 1 root root 180 Jul 31 2013 logrotate -rwxr-xr-x. 1 root root 618 Mar 17 2014 man-db.cron
/etc/cron.hourly: total 20 drwxr-xr-x. 2 root root 44 Sep 25 09:10 . drwxr-xr-x. 115 root root 8192 Oct 14 09:19 .. -rwxr-xr-x 1 root root 392 Jul 27 10:57 0anacron -rwxr-xr-x. 1 root root 362 Mar 9 2015 0yum-hourly.cron
/etc/cron.monthly: total 12 drwxr-xr-x. 2 root root 6 Jun 9 2014 . drwxr-xr-x. 115 root root 8192 Oct 14 09:19 ..
/etc/cron.weekly: total 12 drwxr-xr-x. 2 root root 6 Jun 9 2014 . drwxr-xr-x. 115 root root 8192 Oct 14 09:19 ..
On 10/13/2015 04:44 PM, zep wrote:
On 10/13/2015 09:54 AM, C. L. Martinez wrote:
I haven't entries in conrtab's users file at this moment, but I have done a test: * * * * * ls -la, and it is not triggered. But like I say before, installed system cronjobs like logwatch task are not triggered ... _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I'd say that crontab doesn't actually prove that the job isn't being triggered, it just proves there's an email config/sending/something problem.
if you change that to to something like
- touch /var/tmp/cron-test-file
does it create and keep changing the date on the file?
Nothing ... There is not cron-test-file under /var/tmp ...
On 10/14/2015 04:36 AM, C.L. Martinez wrote:
On 10/13/2015 04:44 PM, zep wrote:
On 10/13/2015 09:54 AM, C. L. Martinez wrote:
I haven't entries in conrtab's users file at this moment, but I have done a test: * * * * * ls -la, and it is not triggered. But like I say before, installed system cronjobs like logwatch task are not triggered ... _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
I'd say that crontab doesn't actually prove that the job isn't being triggered, it just proves there's an email config/sending/something problem.
if you change that to to something like
- touch /var/tmp/cron-test-file
does it create and keep changing the date on the file?
Nothing ... There is not cron-test-file under /var/tmp ...
Try it will /usr/bin/touch .. you may not have environment variables like PATH set.
Because systemwide cronjobs are installed in /etc/cron.* directories, not in root user cron file..
Eero 11.10.2015 7.39 ip. "C. L. Martinez" carlopmart@gmail.com kirjoitti:
On Sunday, October 11, 2015, Jonathan Billings billings@negate.org wrote:
On Oct 11, 2015, at 8:20 AM, C. L. Martinez <carlopmart@gmail.com javascript:;> wrote:
I am having strange problems with my cron jobs in my CentOS7 kvm host. After the initial install and first boot, any cron job configured had run (including cron tasks installed by some rpm packages).
Did you have a question or error to point out? So far all I see is a correctly-running system.
-- Jonathan Billings <billings@negate.org javascript:;>
That's the problem. There is no error but any cron job configured runs.. And this is the cuestion: why any cron job works?.
CentOS mailing list CentOS@centos.org javascript:; https://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Mon, Oct 12, 2015 at 2:59 AM, Eero Volotinen eero.volotinen@iki.fi wrote:
Because systemwide cronjobs are installed in /etc/cron.* directories, not in root user cron file..
Thanks Eero. I know this. And I have tried to put some cron job in these directories to test ... and nothing ...