Hot answers tagged

5

The default behaviour of wget (documented in the manual) is to restart after a default timeout of 900s (aka 15 min). Adding --timeout=0 solves the problem here.


5

The $(date +%F --date "Yesterday") technically isn't a variable, it's a command substitution, but that is tangential to your question. This construct could prove to be problematic if for some reason the date command wasn't in your $PATH, and thusreturned nothing - at which point it would delete everything in /video/. If you instead take that command ...


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 * * * ...


3

Sunday is 0, Monday is 1, etc. http://man7.org/linux/man-pages/man5/crontab.5.html The time and date fields are: field allowed values ----- -------------- ... day of week 0-7 (0 or 7 is Sunday, or use names)


2

First we need to generate the folders we can put scripts in: mkdir ~/.config/cron.hourly mkdir ~/.config/cron.daily mkdir ~/.config/cron.weekly mkdir ~/.config/cron.monthly mkdir ~/.config/cron.yearly mkdir ~/.config/cron.reboot Then we need to run crontab -e to edit our scheduler. If this is you're first time running crontab, you'll need to select your ...


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 ...


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

Two things jump out: You have no checking for failure of the substitution There is a race condition if the date changes between uses of the date command. You could solve them both like this: #/bin/bash # Exit if any command fails set -e dir='/media/jmartin/Cams/video' day=$(date +%F --date Yesterday) # Conbine files from the past 24 hours into a ...


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 ...


1

Since there is always a space in your filenames, I'd include that in your command: rm "$(date +%F --date "Yesterday") "* # Removes old clips That should be an easy way to prevent deleting all files in the directory, as even if date doesn't return anything, it would only delete files starting with a space character (which hopefully do not exist). However ...


1

As long as you get the script right and you don't run it in a weird environment, everything should be fine. But if something breaks the expected output of date, all bets are off. For example, if you run this snippet with IFS=-, then you'll be running something like rm /media/… 04 26* i.e. delete files beginning with 26 in the current directory. Of course ...


1

cron intentionally runs with a limited environment (including a restricted path, it does not have the same path as your standard shell). You either need to run a script (including the full path to the script) which then sets a path variable internally, or you need to set the path in the crontab line itself. One example of that is, 12 0 * * * (export ...


1

try: #!/bin/bash while true; do for user in $(ls /home); do chgrp www-data /home/${user}/private/FILE.TXT done sleep 10 done The infinite loop is for bypassing the cron limitation of 1 minute to repeat a job. make it executable: chmod +x /PATH/TO/owner.sh And just run it without a cronjob. Also if you just want to react to the ...


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.


1

I use either script2log (simple), or vile-pager (vi like emacs) for this sort of thing. The script handles overstrikes of the sort mentioned, as well as backspace/overstriking. To handle cursor-movement (as you would get in editing a command-line), a simple script like this is not adequate. The script removes ANSI-style escape sequences, however. The ...


1

The simplest answer to check if a cronjob works when you expect it to (short of reading the man page) would be to add a simple cronjob that will report the date to a particular file: 0 * * * * date >> /tmp/cronjob.test Then check it the next day (or whenever) and ensure it's triggering when you expected it to. I personally would recommend reading ...


1

cron typically runs things in a fairly minimal environment (man 5 crontab to see what exactly), which probably doesn't have enough in its path for this. If you want to see what is in the path, you can always run printenv > /tmp/cron_env from (presumably at a time in the near future) to see. Generally you can just define an updated PATH in your crontab ...


1

The syslog format typically contains a timestamp, hostname, app name, and process ID along with whatever custom message was sent. All of these values are (substantially) under the control of the process that sends the syslog message. The cronie source (if configured to use syslog) uses the openlog and syslog functions to write to syslog. Seeing that the ...


1

I've found an answer in "How Linux Works" by Brian Ward. I've simply messed the syntax. Deleting the passing of $USER fixed the problem. In other words the file file I am passing to crontab should have following structure: m h dm m dw command and not: m h dm m dw user command And again thank you roaima for useful tips.


1

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 ...



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