Tag Info

New answers tagged

0

I don't have a C7 system to hand but on Fedora the cron daemon is called crond and lives in /usr/sbin. Perhaps you can figure it out from that. (it's easy)


1

You can put SHELL=/bin/bash in your crontab - you can also point to a .bashrc using BASH_ENV="/root/.bashrc". That should get you going. I actually don't know what happens if you don't have SHELL defined, but adding it to crontab makes it easy to tell what is what.


3

The crontab(5) manpage deals with your query by default it's /bin/sh Several environment variables are set up automatically by the cron(8) daemon. SHELL is set to /bin/sh, and LOGNAME and HOME are set from the /etc/passwd line of the crontab?s owner. HOME and SHELL may be over- ridden by settings in the crontab; LOGNAME ...


0

Usually, if a script runs fine on your shell session but not in crontab, this is an environment issue. This could include: working directory shell variables user Make sure that the cronjob is being run by the same user you are using to run the script in your shell. Also, try to use fully qualified paths (/var/www/foo.txt instead of foo.txt) everywhere ...


0

I ended up setting the timezone directly in my application (run by cron), and it works as expected. ENV['TZ'] = 'Europe/Paris'


0

OpenShift runs every file in the .openshift/cron/* directories on the relevant schedule. Thus, we see that first cron.js is being executed by bash and throwing a syntax error. Then immediately afterward cron.sh is being executed. To resolve the problem, get rid of cron.sh and add this to the first line of cron.js: #!/usr/bin/env node var mongoose = ... ...


0

The reason you are experiencing two different behaviors is cron does not run in a shell so all the environmental variables that you have access to in a shell are missing from cron. If you want cron to behave as it does in your shell you need to invoke it in a shell env. For bash that would be: /bin/bash -l -c 'your command'


1

No mater who call the command if the user is on local machine. If you allow root access to %@localhost you can connect to the mysql server with whatever user you have. Example: If you're logged with user test1 you can still connect to the local mysql with user root. user1@machine~$ mysql -h localhost -u root or user1@machine~$ mysqldump -h localhost -u ...


2

Solaris is likely running sendmail. Typical system files that would be involved would be: /etc/mail/aliases /etc/mail/local.cf If the user has a .forward or .vacation file in the home directory, then that may change delivery behavior. Check the logs in /var/adm to see if there are any hints. CHeck any of the messages in the mail queue to see where they ...


2

If you have ntp running and configured correctly, there should be no need to run ntpdate at all. All I typically use it for is to manually set the clock during installation.


0

Try creating script files for your tasks in /usr/local or /opt and call those with cron. From the exitcodes, it seems likely that you managed to create invalid commands in crontab. Some shell builtins (cd, source, etc.) may not be available. I prefer creating scripts for more complex commands to be run by cron. That makes them easier to test too. E.g. for ...


0

You don't have a full tty in cron. But if you run it via sudo -i you'll get one. * * * * * sudo -u user -i bash -c '. $HOME/.bash_profile; . $HOME/.bashrc; env > $HOME/env.log;' Or to start the script: * * * * * sudo -u user -i bash -c '. $HOME/.bash_profile; . $HOME/.bashrc; /home/user/myscript.sh;' If you put the source commands in a Bash script ...


1

To add on to tripleee's answer, you can cause all of your crons to be evaluated in bash (or the shell of your choice) by specifying the shell in the crontab. SHELL=/bin/bash * * * * * . $HOME/.bash_profile; . $HOME/.bashrc; env > $HOME/env.log; edit and if you really want to see what it's doing, the following command should make it sufficiently ...


1

The cron job syntax is restricted to sh only so you cannot use Bashisms like ~. Fortunately, the fix is easy -- just replace it with $HOME. Similarly, source needs to be replaced with . (just a dot). Of course, the scripts you source mustn't use Bash syntax either if you intend to use them from sh. Probably the easiest fix is to migrate these things to ...


0

Directories like /usr/local/bin and /usr/local/sbin are not by default in cronjobs $PATH. But you can redefine $PATH in crontab, simply put something like this before any defined cronjobs PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin


0

The $PATH environment variable under cron is limited, and will include neither /usr/local/bin nor /home/foobar/dir. The correct answer is, as you found, to fully qualify the path to the script in your crontab; it leads to less surprises.


0

$HOSTNAME is set by some shells (like bash), it is not an environment variable Set your shell script to run under bash (put #!/bin/bash as the first line instead of #!/bin/sh) and try again



Top 50 recent answers are included