Hello, I have recently set up a crontab job to backup to a server using Arch linux as the core system. I have edited using VI with no particular issues, however when the job is supposed to start it fails. The journalctl entry for cron states its a permission issue. My question is this: I am the only user on the client and indeed server, my username is philip, I obviously have root privileges. When setting up the crontab using cronie, I am prompted to continue as root. This I think is the issue that the job starts correctly but fails because it expects the user rather than the root? I haven't modified the etc/cron.allow yet. Does anyone know if this would do the trick? thanks
Hello, if your user account (philip) is not permitted to use cron, and you defined a cron job in this particular user's crontab, then adjusting cron.allow is the first thing you should check. Other than that, what are the backup tool's (script, binary?) permissions? Is any non-privileged user allowed to run this tool as an ordinary command? What does the job definition look like? (are you using absolute paths, special characters, etc.?)
Thanks, I will edit cron.allow later and see if this works. The script is an executing bash script (.sh), it works fine manually i.e. backs up just has an issue when cron is engaged. The backyp script uses rsync over ssh. I did modify the ssh config files to accept log in without a password, so I'm going by exclusion......
Hey Zaramaloo. there is only one user that has root privileges and that is root. Try creating a root cron job with 'crontab -e' on the root command line.
Edited what using 'vi'???
You should not be editing crontab files using vi.
You should only use the provided crontab tools to establish a new cron job.
Apologies I edited using "crontab -e" command....it works fine now. The issue with the shell script was related to read/write permissions on the remote server which I had to change using chmod, rgds
That's what "they say".... but to be honest, I always edit crontab files with VI and have never had a problem in like 50 years editing crontab files using VI, ever.
1 Like
@neo Yes, we all kmow that you can, indeed, edit crontabs directly if you are a Unix/Linux Pro and you know exactly what you're doing. In that respect you are in a privileged position but novices often get the format wrong when editing directly so then nothing runs properly, and very often also fail to manually restart the cron daemon to reload the table into memory so they wonder why after the editing the job doesn't run or a deleted job still runs (until the cron daemon periodically wakes up and rescans the tables (and on some distros that can be a full 24 hours)).
The crontab utility notifies the daemon automatically that a new job exists.
Sure, I know that you know all this but that's why I never recommend direct editing of crontabs.
I did assume that an IT Pro would not phrase the question to the Community this way.
Vixie cron and compatibles regularly check the mtime of each file, not only the /etc/cron.d/ files (where manual editing is required) but also the crontab files in /var/spool/cron/
So after a few minutes a manual file editing is noticed.
On systems with inotify (Linux) the kernel will inform the cron daemon immediately.
Using the crontab commands is recommended for portability - it works with all cron versions. And it's independent of the exact file location, e.g. some Linux distros have /var/spool/cron/tabs/ while others have /var/spool/cron/crontabs/
2 Likes
Besides basic (and not really required) syntax checking, the main "risk" using vi to edit or replace cronfiles is the fact that directly writing to the crontab file (including most editors, including stream editors) does not lock the crontab file, and so, two simultaneous edits could have consequences.
However, since editing the crontab file requires a priviledged user (root or sudo, for example) on most systems, it is rare that two super users are editing the crontab file at the same time.
If the system has only one user with privileges to write the crontab file, then there is no chance the lock-file issue can happen, so the remaining issues of "checking syntax" is more of a "nice-to-have" versus a hard requirement.
So, sorry, but I still think that without knowing the context (like how many users are logged into the system or who has superuser / ability to write crontab), saying that "one should not be editing crontab files using vi" is a bit overkill in the majority of situations.
Yes, if you are on a machine with many users with the ability to over-write a crontab and these users who have super-user privs to write a crontab file cannot 'vi' a simple line in a crontab file following basic syntax, then of course using command line cron tools is a good idea.
In the case of @zaramaloo , who said in his original post:
" I am the only user on the client and indeed server .... "
Then I apologize for my honesty, and please do not take it the wrong way, but I think @zaramaloo is OK to 'vi' his crontab file if he wishes, since he is indeed the only user on the system.
The issue which @zaramaloo resolved was a normal, routine permissions error, which happens more-often-than-not when debugging crontab issues!
Cheers.
3 Likes