Tag Info

New answers tagged

1

Marco's script didn't work for me for some reason. I didn't have time to debug, so I wrote a Python script which does the same thing. It's longer, but: first, it works for me, and second, I find it easier to understand. Change "/tmp/cron-env" to where you saved your environment. Here it is: #!/usr/bin/env python from __future__ import division, ...


1

I had a similar issue, I created a new sources.list file which held only the sources I wanted Apticron to work with And then I changed the Apticron code so it will use the file I created. sudo grep "-security" /etc/apt/sources.list | sudo grep -v "#" > /etc/apt/security.sources.list Above command will create a new sources list specifically for ...


0

Update: I see this is the syslog for the crontab that is setup to run at the beginning of the day to restart samba and nothing else in the syslog: Dec 19 00:00:01 storage /USR/SBIN/CRON[25935]: (root) CMD (/etc/init.d/samba restart) I get this in my email report setup: Stopping Samba daemons: nmbd/etc/init.d/samba: 119: start-stop-daemon: not found ...


0

Your crontab should look like this: 0 * * * * /etc/init.d/samba restart >> /dev/null 2>&1 Also be sure you are sudo when editing this cron, eg. with: sudo crontab -e


1

chkcrontab works perfectly to me! Thanks Dave. Unfortunately, this site doesn't me to vote yet. To install it (as root user, or use with the prefix command sudo): pip install chkcrontab If you haven't pip installed, try before: apt-get update apt-get install python-pip


0

Although I'm not entirely sure why this is happening, it seems to be that long running jobs inside cron cause an odd behaviour. In the original post have a series of jobs that are fired every five minutes and some one minute after each other. If the first job takes too long (10 minutes for example) my guess is that the forked process of the first job is ...


0

tar cvfz site_backup.tar.gz /path/to/your/user/public_html/ should be enough here, however it's better if you backup this using the cpanel functionality and do it to a remote ftp server. Additionally you can use something like www.backupsetc.com to backup you cpanel account, using it is pretty straight-forward(you just have to specify your server and ...


2

The OpenShift cron directories are meant to contain the actual scripts to be run, not traditional crontab-style entries. So you should instead write a simple script to call your PHP code. #!/bin/bash /opt/rh/php54/root/usr/bin/php ../../../cron/status.cron.php


5

Either remove wget exclusion from the nginx configuration, or add something like this as an option to your wget command: --user-agent="Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:21.0) Gecko/20100101 Firefox/21.0" --referrer whatever.example.com


-1

Thanks alot for your answer. But the syntax didnot work for my particular problem. Anyway, I used this code to get it all work: 0 * * * * root -O- http : // [ url ] >> /folder/text.txt I had to difine user name and -O- paramater with two bigger than '>>' sign. Now everthing works as expected. :)


4

The correct form would be 0 * * * * wget http://<URL> > /path/to/file e.g. 0 * * * * wget http://www.serverfault.com > /tmp/serverfault.html But if the URL gets more complicated, you might need to escape characters and/or put this in quotes.


0

According to the man page for Signal (man 7 signal) a SIGBUS means Bus error (bad memory access). Since the problem is random or not easily reproduced 100% of the time, this means either; The Cron job is calling a program or script that is randomly failing A memory problem exists and should be checked for If it is the former (#1), then check the program ...


1

You can try the following: create a file before the job starts and remove it, when it finished. 20 minutes after the job starts check if the file exists. If so then send a notification 00 07 * * * touch /tmp/run_trans_push.started; /u01/home/oracle/sysadm/run_trans_push.sh > /u01/home/oracle/trc/run_trans_push.sh_`date +\%b_\%d`.trc 2>&1; rm -f ...


0

So, afaict SES requires a domain in both the "from" and "to" fields. While MAILFROM= is not supported on Ubuntu's cron, you can set FromLineOverride=NO in ssmtp.conf, and ssmtp will force the "from" address to be "root@hostname" instead of just "root". This takes care of the "from" address. Now - you also need to make sure that the "to" address has a ...


0

Found it! The reason why the email could not be send is, that the user "tst" has in my case no own and already created home directory. After create the home directory for user tst it works like expected! :-)


0

Enable logging for the job-execution subsystems. More specifically, cron and at will log to syslog by default, so you simply need to ensure the logged events are persisted. You might want to add the following to your /etc/syslog.conf ## Log cron and at to /var/adm/scheduled.log cron.* /var/adm/scheduled.log After adding that, reboot the syslog daemon, to ...


0

You could check the parent process name by using the ${PPID} environment variable and looking for that in ps.


1

Restarting your servers for "sanitation purposes" is a poor approach to administration. Do not do this unless you are installing updates or have legitimate reasoning to. If you actually want to proceed and you assume your database server is going to take a while to reboot (and your web server isn't), you could just schedule the reboot on the web server to ...


0

Your problem seems to be that your Groovy doesn't run from cron at all, so it just keep sending the same email. What you can do, add to top of your script: source /etc/bashrc The full line could look like this: 30 * * * * source /etc/bashrc; /opt/groovy/bin/groovy /path/to/groovy/script.groovy >>/var/log/MyGroovyScript-stdout.log ...


0

Firstly I would check syslog & have a look what kind of error message the crond is producing. If you are not getting any output, try adding the -e php option. Secondly, try using quotes ("cmd") around the command. There may be a problem interpreting the command options. Hope this was helpful.


1

Check the persistent temp directory /var/tmp/ for a Vi.recover directory.


2

The permission for your crontab is wrong, it is owned by an (nonexistant?) user with the uid 1001, not the user gauthier (or you have some further issues with your system if your uid is 1001). Try sudo chown gauthier /var/spool/cron/crontabs/gauthier and see if this fixes this.


-1

have you check cron.allow/cron.deny ? as per man crontab says: you must be listed in cron.allow if it exist. you must not be listed in cron.deny if it exists. one of these file must exists.


0

You can edit your user crontab if you have superuser access, without modifying permissions: $ sudo crontab -u username -e I thought you could edit your user crontab without sudo, but I get the same permission issues as you, even after adding myself to the crontab group. The permissions in my user's crontab (/var/spool/cron/crontabs) are -rw-------, group ...



Top 50 recent answers are included