I’m getting a little lost in the other (very welcome!) issues raised in the thread.
My current state of play is:
Crond has been enabled in qvm service crond status confirms that crond is up when the AppVM is running
there is an entry in the rc.local to replace /etc/crontab with /rw/home/user/path/to/new/crontab
the script which is invoked in the crontab, runs fine when run manually and doesn’t require sudo
Tl;dr - Crond is running (in a Fedora based AppVM), the script backup.sh runs fine when invoked, crontab is rewritten upon boot to
* * * * * user /rw/home/user/path/to/./backup.sh
I’ve tried it with ‘user’ and without ‘user’, no difference. Cron doesn’t seem to have logs so can’t find whether the issue is with the crontab edit, some permissions thing or something more fundamental.
One reason why I hate forums like this - they make it incredibly
difficult to follow lines of discussion within a single thread.
My remark was directed toward @9009 who complained that the FileCopy
dialog opened.
It looks like cron(ie) does not get installed by default in Fedora 32. qvm-service [appvm] crond only determines if the service is “enabled” from a Qubes OS perspective. The issue here is that the packages for cron aren’t even installed - perhaps this is a Fedora 32 template bug? My Debian 10 template already had cron installed by default.
In your Fedora 32 template, execute:
sudo dnf install cronie
Shut down the template and your AppVM.
Ensure you have the crond service enabled by Qubes; in dom0:
qvm-service [appvm] crond on
Now, cron will be enabled in the appvm. To verify, boot the appvm, and check:
systemctl status crond
Result should have Active: active (running) (on Debian, change crond to cron).
This the baseline - making sure cron(d) is running before changing anything. If the above doesn’t check out, you have to resolve that first.
At this point now you can make your changes.
When you enable crond from Qubes OS (with qvm-service), Qubes redirects the crontabs that would normally be stored on the root file system to be to be stored persistently within the AppVM under /rw/bind-dirs/var/spool/cron. The system-wide root crontab at /etc/crontab is not affected.
To stay in the “Qubes OS” lane as well as being a little more declarative, I would suggest to leave /etc/crontab alone and place your cron entries in the crontab for the user user.
In your appvm, have these files:
~user/backup/backup.sh: Performs the backup commands
~user/backup/crontab: Contains crontab entry to exec backup.sh:
* * * * * ~user/backup/backup.sh
Assuming you have no other crontab things to add for this AppVM, set the crontab for the user:
$ crontab ~user/backup/crontab
Logs? Check journalctl -u crond in Fedora or journalctl -u cron in Debian. This will tell you when crond is triggered.
If your backup.sh script generates output, check user’s mail with the mail command. Or, make sure backup.sh redirects output within the script itself to a file…or change the crontab…etc.
OP has already stated that they have confirmed that crond is up when the
appVM is running - “crond status confirms that crond is up when the AppVM
is running” - so much of your explanation is not particularly helpful.
@JustAnotherQubesUser - Is there a chance that you can post the contents
of the backup.sh file, anonymised if possible?
When I am in the AppVm, and run crontab -e, I am seeing the modified file above.
However, when I check the status of crond via sudo service crond status I see the following:
Redirecting to /bin/systemctl status crond.service
● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
Drop-In: /usr/lib/systemd/system/crond.service.d
└─30_qubes.conf
Active: active (running) since Mon 2020-12-21 14:41:40 GMT; 8min ago
Main PID: 667 (crond)
Tasks: 1 (limit: 4840)
Memory: 1.5M
CPU: 168ms
CGroup: /system.slice/crond.service
└─667 /usr/sbin/crond -n
Dec 21 14:41:40 phd crond[667]: (CRON) STARTUP (1.5.5)
Dec 21 14:41:40 phd crond[667]: (CRON) INFO (Syslog will be used instead of sendmail.)
Dec 21 14:41:40 phd crond[667]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 24% if used.)
Dec 21 14:41:40 phd crond[667]: (root) BAD FILE MODE (/etc/crontab)
Dec 21 14:41:40 phd crond[667]: (CRON) INFO (running with inotify support)
Dec 21 14:41:40 phd crond[667]: (CRON) INFO (@reboot jobs will be run at computer's startup.)
Dec 21 14:41:40 phd systemd[1]: Stopping Command Scheduler...
Dec 21 14:41:40 phd systemd[1]: crond.service: Succeeded.
Dec 21 14:41:40 phd systemd[1]: Stopped Command Scheduler.
Dec 21 14:41:40 phd systemd[1]: Started Command Scheduler.
The bit that is interesting is:
Dec 21 14:41:40 phd crond[667]: (root) BAD FILE MODE (/etc/crontab)
/etc/crontab is owned by root:root and have permissions 644: -rw-r--r-- 1 root:root <sixe> <date> /etc/crontab
The file you are linking in place should have same permissions.
(If you are doing this I would copy /etc/crontab to /rw, and then in
/rw/config/rc.local:
rm /etc/crontab
ls -s /rw/crontab /etc/crontab
systemctl restart crond
But, of course, I wouldn’t be doing this at all - that’s what native
Qubes use of bind-dirs and qvm-service crond is for.
And as unman indicated, I missed the part when it was mentioned crond was running - I assumed you meant qvm-service appvm crond says “on” (though “enabled” is a better description)…so skip the first half.
But the rest explains qvm-service, bind-dirs, and how to edit the crontab - you can do it interactively with crontab -e or crontab [filename] if you have a file with the cron jobs specified in them already.