Hot answers tagged

4

Would not be better if you compress your files and keep less of older logs instead of spending time creating a script? THIS is why logrotate exists. Take a look at your logrotate.conf. It should start with something like this: # see "man logrotate" for details # rotate log files weekly weekly # keep 4 weeks worth of backlogs rotate 4 # create new (empty) ...


3

First rule of crond club: you don't assume the working directory. My guess is that you'll find a crond.log in /root. If you want it in /vagrant, explicitly redirect the output to /vagrant/crond.log. (FWIW, the second rule of crondclub is: don't assume there's anything in your PATH, use explicit paths to binaries, but since echo is also a bash builtin, ...


3

There are several places where cron-jobs are stored. The main place, is /etc/crontab (and on some systems, this is the only one). This file is edited only by root, and often allows to specify which user the job should run as. On some systems, there is also a directory - /etc/cron.d - which complement /etc/crontab. The files here contains line(s) like ...


3

Solution to the problem is to modify the entries in cron with the absolute path names. Added cron command logging capability as the machine doesn't have an MTA to send failure notifications, as follows: 0 0 * * * /usr/local/bin/bitcoind -datadir=/home/pi/bitcoinData -daemon >> ~/bitcoinData/bitcoin-cron.log 2>&1 0 6 * * * ...


2

Applications run from cron have no "console". Both stdout and stderr are captured and emailed to the local user account when the job completes. In your case the script is run as root, so the result will in in root's email. As for writing to the file, the ~ represents the root user's home directory, i.e. /root, so that is where you need to look for the ...


2

Here are some points about those two (hope would answer your questions): 1. checking what your cron job really does can be kind of a mess, but all systemd timer events are carefully logged in systemd journal like the other systemd units based on the event that makes things much easier. 2. systemd timers are systemd services with all their ...


2

Don't edit a crontab file directly. Use the crontab command, that's what it's for. Don't use sudo multiple times in a script. Run the entire script with sudo. Quote your variables and strings properly. Single-quotes around literal strings, Double-quotes for variable etc interpolation. You should be grepping for fixed strings rather than regular ...


2

For cron edit purpose l0b0 answer is the best way, to fix your script you have to: escape dots and asterisk in your search key (updateKey) use alternative separator in sed (I choose %) double quotes around sed expression (you want your bash variables resolved) #!/bin/bash CCgenerator="0 06,18 * * * /home/server/scripts/CCgenerator.sh" updateKey="0 05 ...


2

Rather than update the crontab directly you'll want to use a standard mechanism to add a cron job: line="* * * * * /path/to/command" (crontab -u userhere -l; echo "$line" ) | crontab -u userhere -


2

Does /temp really exist (didn't you mean /tmp)? If it doesn't then your script tries to cd to /temp, fails, and then all the commands run in the starting directory. The last two commands are particularly dangerous because you cd to /, then cd to /temp (which may not exist) and then rm everything (which could well be the root filesystem). You should ...


2

root has full access on your system, but doesn't necessarily have all the keys to other systems that your normal user account has. So the trouble is: rsync -avz /home/user/backup user@myserver:/home/user/ ^^^^ If you cause root to execute this command as you, your keys will be used and the command will be successful: sudo -u ...


2

crontab entries are processed independently, so yes, the jobs are run asynchronously, in parallel. You don't need to background them. If you ever need to synchronise jobs, check out the techniques mentioned in Can a crontab job run concurrently with itself?.


2

To find the filenames and script types of all scripts run from cron by non-root users (does not identify user): find /var/spool/cron/crontabs/ -type f ! -name 'root' \ -exec awk '!/^[[:blank:]]*(#|$)/ {print $6}' {} + | xargs -d'\n' file | grep -i script /home/cas/scripts/fetch.sh: Bourne-Again shell script, ASCII text executable ...


2

The entries are added to the log each time a cron job runs. To reduce the time between entries, you would have to look at your cron jobs and change their timings. This, though, may break something that relies on those jobs running at specific intervals. If they really do annoy you, then simply follow the instructions on the Debian bug report and stop cron ...


1

man 5 crontab suggests that a cronjob will find the owning user's username in the LOGNAME environment variable: 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 can be overridden by settings ...


1

Get the script's owner On any system with as stat that is compatible with modern GNU stat, the user ID of the owner of the script is: stat -c %u "$0" The user name of the owner of the script is: stat -c %U "$0" In general on linux, stat -c %U file returns the owner of file. We substitute in $0 because that variable typically contains the name of ...


1

You seem to look at your crontab with crontab -l. The corresponding command for editing crontabs is crontab -e. This command will edit crontabs that are generally in the directory /var/spool/cron/crontabs/. In this directory you will find files named after usernames owning the crontab.


1

The functions called (get_review_data, save_stats, check_for_new_reviews, etc.) should be listed within the php code and python code, /home/mycompany/public_html/index.php and /home/scraper/scraper.py Examining those files should show what's actually being executed.


1

The exact sequence in which jobs are executed will depend on the implementation of your systems' crond. What is your OS? If you have cronjob in a crontab: Job 1 Job 2 Job 3 In Debian Job1 will start, without waiting to finish Job 2, etc. In Debian and Ubuntu derivatives it is top-bottom In FreeBSD it is bottom-top If your cronjobs are in ...


1

Couldn't I run something like daemontools to monitor and restart the process? Yes, indeed; and on some machines I do exactly that. The "something like daemontools" is actually the service manager from the nosh package but other members of the daemontools family are more than capable of supervising GNU cron. (Vixie cron is another matter, but you did ...


1

It's written but not where you're looking for. The best way is using absolute paths.


1

In my opinion you should never ever disable the root user entirely. If you do not want to be able to login as root using ssh you should set the directive PermitRootLogin no in /etc/ssh/sshd_config. For other applications there are mostly equivalent settings which can be made.



Only top voted, non community-wiki answers of a minimum length are eligible