I'm trying to make cron jobs or task schduler working, but I can not figure out why my script is not taken in consideration.
I'm trying to simply archive a folder with:
tar -cvf /volume1/NetBackup/Backups/Monday.tgz /volume1/NetBackup/Backups/ns3268116.ovh.net/
Each time the script starts working but cannot achieve the work. Either with task scheduler or crontab, a file Monday.tgz is created in folder /volume1/NetBackup/Backups/, but this file is only 1024 bytes.
Synology Cron is really fussy.
Here are my own personal notes for Synology DS413j, DSM 5.2:
Hand edit /etc/crontab as root, crontab -e isn't available
Ensure you use tabs not spaces to separate the columns
Your crontab changes may not survive a reboot if there are syntax problems
The who column in crontab may not be reliable. Use root in the who column and /bin/su -c '<command>' <username> to run as another other user
remember that it uses ash not bash so check for bashisms, e.g use >> /path/to/logfile 2>&1' not&>> /path/to/logfile`
It doesn't support 'MAILTO='
you need to restart crond synoservicectl --reload crond for the new crontab to take effect
You may try adding some diagnostics to it. For instance:
Add MAILTO into the crontab file (on top of crontab -e) to receive cron errors by email:
MAILTO=username#domain.com
Redirect output of your tar command to the file:
your command > ~/log.txt 2>&1
Check cron log and look for anomalies. For instance (it may depend on your configuration):
/var/log/cron.log
You may also try searching through /var/log/messages at the time of your cron job.
Is volume1 a resource on remote host? If yes, it is worth checking this part of the system.
I agree about the really nagging nature of Crontab on Synology Linux OSs.
I would certainly suggest to create de desired job as a .sh shell script and call it via CRON task inserted by using the GUI, as suggested here.
As for today (March 2017) is the best method I have found, since working with crontab via CLI is nearly a pain.
Related
Docker best practices state:
If a service can run without privileges, use USER to change to a non-root user.
In the case of cron, that doesn't seem practical as cron needs root privileges to function properly. The executable that cron runs, however, does NOT need root privileges. Therefore, I run cron itself as the root user, but call my crontab script to run the executable (in this case, a simple Python FTP download script I wrote) as a non-root user via the crontab -u <user> command.
The cron/Docker interactability and community experience still seems to be in its infancy, but there are some pretty good solutions out there. Utilizing lessons gleaned from this and this great posts, I arrived at a Dockerfile that looks something like this:
FROM python:3.7.4-alpine
RUN adduser -S riptusk331
WORKDIR /home/riptusk331
... boilerplate not necessary to post here ...
COPY mycron /etc/cron.d/mycron
RUN chmod 644 /etc/cron.d/mycron
RUN crontab -u riptusk331 /etc/cron.d/mycron
CMD ["crond", "-f", "-l", "0"]
and the mycron file is just a simple python execution running every minute
* * * * * /home/riptusk331/venv/bin/python3 /home/riptusk331/ftp.py
This works perfectly fine, but I am unsure of how exactly logging is being handled here. I do not see anything saved in /var/log/cron. I can see the output of cron and ftp.py on my terminal, as well as in the container logs if I pull it up in Kitematic. But I have no idea what is actually going on here.
So my first question(s) are: how is logging & output being handled here (without any redirects after the cron job), and is this implementation method ok & secure?
VonC's answer to this post suggests appending > /proc/1/fd/1 2>/proc/1/fd/2 to your cron job to redirect output to Docker's stdout and stderr. This is where I both get a little confused, and run into trouble.
My crontab file now looks like this
* * * * * /home/riptusk331/venv/bin/python3 /home/riptusk331/ftp.py > /proc/1/fd/1 2>/proc/1/fd/2
The output without any redirection appeared to be going to stdout/stderr already, but I am not entirely sure. I just know it was showing up on my terminal. So why would this redirect be needed?
When I add this redirect, I run into permissioning issues. Recall that this crontab is being called as the non-root user riptusk331. Because of this, I don't have root access and get the following error:
/bin/ash: can't create /proc/1/fd/1: Permission denied
The Alpine base images are based on a compact tool set called BusyBox and when you run crond here you're getting the BusyBox cron and not any other implementation. Its documentation is a little sparse, but if you look at the crond source (in C) what you'll find is that there is not any redirection at all when it goes to run a job (see the non-sendmail version of start_one_job); the job's stdout and stderr are crond's stdout and stderr. In Docker, since crond is the container primary process, that in turn becomes the container's output stream.
Anything that shows up in docker logs definitionally went to stdout or stderr or the container's main process. If this cron implementation wrote your job's output directly there, there's nothing wrong or insecure with taking advantage of that.
In heavier-weight container orchestration systems, there is some way to run a container on a schedule (Kubernetes CronJobs, Nomad periodic jobs). You might find it easier and more consistent with these systems to set up a container that runs your job once and then exits, and then to set up the host's cron to run your container (necessarily, as root).
You need to allow the CAP_SETGID to run crond as user, this can be a security risk if it is set to all busybox binary but you can use dcron package instead of busybox's builtin crond and set the CAP_SETGID just on that program. Here is what you need to add for Alpine, using riptusk331 as running user
USER root
# crond needs root, so install dcron and cap package and set the capabilities
# on dcron binary https://github.com/inter169/systs/blob/master/alpine/crond/README.md
RUN apk add --no-cache dcron libcap && \
chown riptusk331:riptusk331 /usr/sbin/crond && \
setcap cap_setgid=ep /usr/sbin/crond
USER riptusk331
I want to edit system cron tab (/etc/crontab). I read that crontab -e is the best way to edit crontab and you need not restart cron services if you edit this way. However I am not able to edit /etc/crontab using crontab -e (this command edits the crontab associated with the user, not system crontab). So is there any better way of editing /etc/crontab (other than using VI editor- which I am doing now). Do I need to restart cron services if I edit /etc/crontab using VI edior?
There are two ways of cronjobs, one is by editing /etc/crontab and sending a SIGHUP the cron daemon. The other way is to use crontab -e to edit
a crontab entry, which is done for the current user or the one mentioned with -u. The -u option can only be used by root. The crontabs
created this way can be found in the directory
/var/spool/cron/crontabs/
and are named after the user with which uid the jobs will be started. In this case you don't need to SIGHUP cron, a normal user can't do this anyway.
Note: The syntax is slightly different to /etc/crontab: You can't enter an other user name to execute the cronjob.
You could do something like this
echo "0 23 * * * yum -y update > /dev/null 2>&1" >> /var/spool/cron/root
Then verify with
crontab -l
I developed a script in which I add lines to the crontab file with echo command and I remove lines with sed command.
I do not know the risk of that especially that I find in some web site that we have to edit crontab file with
crontab -e
What is the risk of does not using crontab -e?
Are there a risk that my edit will not taken account in the cron
schedule?
Should I restart cron with /etc/init.d/cron restart?
The main risk to not using crontab to edit or replace cronfiles is that directly writing to the cronfile (including using sed to do so) does not lock the file, and therefore two simultaneous edits could have unpredictable and even disastrous consequences.
You don't have to use crontab -e; the following forms of editing are semi-safe, in the sense that they won't randomly combine two edits. (But they are still unsafe; an edit could be overwritten):
To add lines:
{ crontab -u user -l; echo "$this"; echo "$this_too"; } | crontab -u user -
To delete lines or do more complicated edits:
crontab -u user -l | sed "$my_wonderful_sed_script" | crontab -u user -
In any case, you don't need to restart cron. It will notice the changed modification time of the cronfile.
When editing the crontab file using your regular editor, the schedule will not be updated. The system will still do the scheduled tasks as before the edit. This will drive the administrator mad.
When cron restarts, such as a reboot or a restart of the process, the current crontab files will be read and processes are scheduled as described in the current present files.
I remember sending a 'kill -HUP' or 'kill -15' to the PID of the cron process to force the process flushing the cache and reading the crontab files again.
I'm using #reboot ~/www/example.com/bin/server in my user's crontab...but when I reboot the server, the web server (this script) does not come up. (script works fine from command line).
My guess is the /home/user directory has not been mounted yet...does anyone know if its possible to get a script to run out of a home directory using this crontab #reboot method?
If you think /home/user hasn't been mounted (or some required systems aren't running) yet, in your crontab line, you can always wait before executing a command like:
#reboot sleep 60; /home/user/www/example.com/bin/server
It should definitely be due to the environment scenarios as given in comments. Try the following and check once by doing a reboot
#reboot (date > /tmp/date-check.txt)
To be sure cron is able to run the jobs.
My problem was that the crontab did not have a full environment. I made the script it was pointing to source my .bashrc.
#reboot /home/user/www/example.com/bin/server
./server does . /home/user/.bashrc to get a working environment.
In Ubuntu if you are using the Home Directory Encryption feature turned on then #reboot in your crontab file won't work as the file system is still encrypted when the system is starting up and cron runs its #reboot jobs.
Your options are to place your files in an unencrypted location (/usr/local/bin or something?) or disable Home Directory encryption on your home directory.
I want to get the details of the last run cron job. If the job is interrupted due to some internal problems, I want to re-run the cron job.
Note: I don't have superuser privilege.
You can see the date, time, user and command of previously executed cron jobs using:
grep CRON /var/log/syslog
This will show all cron jobs. If you only wanted to see jobs run by a certain user, you would use something like this:
grep CRON.*\(root\) /var/log/syslog
Note that cron logs at the start of a job so you may want to have lengthy jobs keep their own completion logs; if the system went down halfway through a job, it would still be in the log!
Edit: If you don't have root access, you will have to keep your own job logs. This can be done simply by tacking the following onto the end of your job command:
&& date > /home/user/last_completed
The file /home/user/last_completed would always contain the last date and time the job completed. You would use >> instead of > if you wanted to append completion dates to the file.
You could also achieve the same by putting your command in a small bash or sh script and have cron execute that file.
#!/bin/bash
[command]
date > /home/user/last_completed
The crontab for this would be:
* * * * * bash /path/to/script.bash
/var/log/cron contains cron job logs. But you need a root privilege to see.
CentOs,
sudo grep CRON /var/log/cron