Newb Cron Question

User Support
17

You don’t need to make any entry in rc.local or symlink - Qubes has already covered
this as you will see if you examine /rw/bind-dirs/var/spool/cron, and
cron will work out of the box when you enable the service.

You should use crontab -e to create and change crontab entries.
I see your entry:
* * * * * user /rw/home/user/path/to/./backup.sh

Can you try that without the user field?
It would be helpful if you posted the contents of backup.sh

1 Like
18 
$ sudo systemctl status cron
● cron.service - Regular background program processing daemon
   Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: enabled)
  Drop-In: /usr/lib/systemd/system/cron.service.d
           └─30_qubes.conf
   Active: inactive (dead)
Condition: start condition failed at Sat 2020-12-19 13:03:38 CET; 8min ago
           └─ ConditionPathExists=/var/run/qubes-service/crond was not met
     Docs: man:cron(8)

Dec 19 13:03:38 VM systemd[1]: Condition check resulted in Regular background program processing daemon being skipped.

I’ve tried sudo and user crontab now, but doesn’t look like anything is being done. /var/run/qubes-service/crond doesn’t exist.

19

I thought you said this was a Fedora based qube? The service there is
crond isn’t it?
Are you now using a different template?
The error suggests that you have not enabled the crond service:
qvm-service -e <qube> crond

1 Like
20

I’m not the OP, but could use some help as well. Looks like the services are different in Debian, since after running that command I still get the same output.

21

The services are different in Debian, but the command is the same, and
the required file is the same. (Qubes cleverness)
Did you restart the qube after issuing the command?

1 Like
22

There is also a discussion on the mailinglist. I though I’d link it here (read-only):

23

Nice, cron works now after a reboot.
However, the Filecopy dialog still pops up, after changing the /etc/qubes-rpc/policy/qubes.FileCopy, since the source VM doesn’t know which VM it’s being sent to, for security reasons.

Edit: Command seems to be qrexec-client-vm cloud qubes.FileCopy file.txt

But I still get permission denied. I tried both qubes.FileCopy and qubes.Filecopy files.

24

OP here.

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.

Any help?

25

If you have an entry:
qube $default allow,target=qube2

Then the pop up wont appear, and files will be automatically copied to
qube2.

26

I’m not quite following you - I’m not copying files between AppVMs, I’m rsyncing between an AppVm and a remote server.

27

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.

28

My bad!

29

Not your fault - blame the forum format.

30

qvm-copy-to-vm was the command I was seeking, which works, although it is deprecated.

A basic syntax like destvm targetvm allow works. Although I’m unsure if it’s qubes.FileCopy or qubes.Filecopy, I’ve seen mentions of both in the docs.

31

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.

32

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?

33

I wasn’t aware of the ‘cron’ folder in /rw/bind-dirs/var/spool/

However, the directory is empty.

I’ve run the crontab command you suggest, but not seeing any change…

Will post the script shortly.

34

The folder is empty because you edited /etc/crontab directly instead of using
crontab -e which is the better method.

If you don’t want to post your script, here’s one you can try:

#!/bin/bash
/usr/bin/date >> /home/user/log

Save that as /home/user/test.sh owned by root
chmod +x test.sh

Entry in /etc/crontab:

          • user /home/user/test.sh

systecmctl reload crond
You should see the log file incrementing every minute.
Report back

35

Here is the script:

#!/bin/bash

LOG_FILE=/rw/home/user/Cron/backup.log
exec > >(tee ${LOG_FILE}) 2>&1

if ping -c 1 IP ADDRESS >> /dev/null
then
echo $(date -u) "Backup Script has run"
rsync -azP /path/to/file user@ipaddress:/path/to/file/
else
echo $(date -u) "Remote host not found"
exit
fi
exit
36

Here is my modified crontab file

SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root

# For details see man 4 crontabs

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name  command to be executed
* * * * * /rw/home/user/Cron/./backup.sh