Tag Info

New answers tagged

1

No, there's no way to reliably detect the exit code of all commands in the example above. Why can't you add all 4 commands inside a small bash script and use: 0 * * * * cronwrapper -c "script.sh" This way you'll be able to better handle any errors inside your script You may also want to enable bash pipefail for some_command | some_other_command See the ...


0

I know this is an old post but to get mine to work I also needed to add a path variable. Otherwise cron may not be able find scrapy. For me it was: PATH=/usr/local/bin Just locate the scrapy binary and add the path variable to a location before the cronjob in the file. I usually use crontab -e to edit the cronjob list. But utilities like webmin can also do ...


0

What if you move that particular line to another location in your crontab file? Does some other cron job then start failing? The fact that the cronjob sometimes works makes this more difficult to solve. Have you ever tried to run strace against the cron process around 21:00 and see what it does?


1

The original cron required each entry to end with a newline so yes sometimes you do need a blank line or something at the end. Although cron requires that each entry in a crontab end in a newline character, neither the crontab command nor the cron daemon will detect this error. Instead, the crontab will appear to load normally. However, the ...


0

Another option is to use pstree $ pstree -lp | grep crond |-crond(2059)-+-crond(4445)---sh(4452) | `-crond(4446)---sh(4453) In this case both PID 4452 and 4453 are scripts that were launched via crond.


0

I had to solve this issue globally for all users and not specific one. I've tried to set up /etc/environment and /etc/default/locale then restart cron. This didn't help. Right answer for me was using env command in upstart script(i am running ubuntu server): env LC_ALL=en_US.UTF-8 cat /etc/init/cron.conf # cron - regular background program processing ...


0

You can move /etc/init.d/cron to something like /etc/init.d/cron_r and create a new /etc/init.d/cron with something like bash -x /etc/init.d/cron_r $1 2>&1 | logger in it, reboot and then check messages log.


2

Make sure that the from email Address is the correct one and the MX and Reverse DNS records for the domain and server IP are properly configured. Once the email server is configured properly, Email services like Gmail, yahoo, etc... will start marking your emails as Valid and will deliver it in your inbox and not in SPAM folder. Hope this helps.


-3

In you favourite E-Mail Client, add cron "From:" address to your address book and select in spam settings something like "Never mark messagess from my contact list as spam".


2

TZ=CET at the top of your crontab will set the time zone for jobs run from cron but won't affect cron's interpretation of times for when jobs start. If you want to set the time zone for cron as a whole then adding export TZ=CET to /etc/sysconfig/crond (or wherever the equivalent config is for your distribution) should change cron's idea of time. You ...


0

Problem in this case was that message had been delivered to spam folder on gmail (which is always worth checking). Adding sender as a contact should avoid this. Apart from that, looking at the received message's full headers may give clues as to why it was flagged as spam (and so how to influence filtering not to do this).


5

You can use the MAILTO option in crontab to define your email address and receive all output and errors in all crons running. open crontab using crontab -e on the top of the file use MAILTO option as MAILTO=email@example.com cron looks for MAILTO feature to decide where it should send cron logs. it send is to root by default if the crons are running ...


-2

On FreeBSD 1: Check log: tail -f /var/log/cron tail -f /var/log/maillog 2: Replace sendmail with ssmtp vi /etc/rc.conf file.. and add: sendmail_enable="NO" sendmail_submit_enable="NO" sendmail_outbound_enable="NO" sendmail_msp_queue_enable="NO" 3: Launch following commands: killall sendmail cd /usr/ports/mail/ssmtp/ make install replace clean 4: ...


0

Marco's solution didn't work for me but Noam's python script worked. Here is slight modification to Marco's script that made it work for me: #!/bin/sh . "$1" exec /usr/bin/env -i "$SHELL" -c "set -a;. $1; $2" The added set -a export variables defined in script $1 and made it available to command $2 p.s. Noam's python worked because it 'exported' ...


1

Webalizer is not configured correctly, as there's no configuration file. To use it, copy webalizer.conf.sample to webalizer.conf and modify it to fit your setup and needs. You can also create more than one configuration file with .conf, as the cron job runs through all *.conf (/etc/cron.daily/webalizer): for i in ${WEBALIZER_CONFDIR}/*.conf; do [...] ...


2

[a-Z] works as intended with locale fr_FR.UTF-8, and probably with all UTF8 locales, but not with "C" locale, as previously answered. A script run from cron inherits no locale, whereas the same script tested from command line inherits user locale (xx_XX.UTF-8). This explains the different behaviour.


1

I had the same problem and the solution was, to grant root group rights: chmod 440 /root/backup.key After that cron was able to read the file, and the backup script run flawlessly.


4

Sounds like (a) root's crontab is initially empty and (b) the -e option is set in the shell. If the user's crontab file is empty then crontab -l exits with status 1. If shell is running with -e option then it will exit immediately on failure (defined as exiting with non-zero status). Look for errexit in the output of echo $SHELLOPTS to check for this ...


1

You can use the package fcron, and run the cron process in foreground mode: fcron -f


1

To stop CRON from running on any run level you can do the following: update-rc.d cron remove When you renamed cron to cron.disabled in init.d, this will probably still work as the links are still active in all the run levels. When you want CRON back as usual you can run. update-rc.d cron defaults If you run either command with -n (it will show you ...


2

If you really want to prevent cron from sending email, you would run the service with "-m off -s" arguments. "-m off" disables cron emails "-s" sends any output not captured to syslog That's presuming you want cron email completely disabled, rather than just for a given entry.


1

I'm not sure it will, but lets fix this properly. The ordering of the redirection matters. What you are trying to do, is to log both stderr and stdout messages to that file, so you should: ... >/var/log/cron/cmd_dispatch.log 2>&1 See also https://www.gnu.org/software/bash/manual/html_node/Redirections.html


0

I get the feeling that you're trying to use cron as a process supervisor. (@reboot is once while * * * * * is every minute). Better idea 1: Use systemd (I think that what's EL 7 systems are using, I've yet to really play with it myself). Better idea 2: Have a init-script that starts the service and manages a lock file (/var/log/subsys/SERVICE would be ...


0

Yes, it is possible (and very probable). A crude solution is to instruct your script to sleep some time. For example, change your cron line as below: * * * * * sleep 60; python script.py This will wait 60 seconds, which should give MySQL time to start. If you had to be absolutely sure that mysql process started before your script runs, you can write a ...


0

Yes, this is absolutely possible. Cron is an important service on every system and will likely start before something like MySQL. While it might be possible to alter the order, this has the potential to screw up your system if you are not extra careful. A better alternative would be to just add a delay to your cron script so it waits long enough that MySQL ...


0

Yes, the cron daemon could quite easily startup before mysql has completed (or even begun) its startup process.



Top 50 recent answers are included