Newb Cron Question

Thanks @unman

Yes, I have enabled the crond service in qvm, and have confirmed that it is running when the AppVm starts.

From what I can make out, the problem is either:

an incorrect syntax in the crontab entry; or
In fedora, you should be using a different service

There is, I guess, a potential third issue in that the permissions may be incorrect for the symlink.

To recap:

  • 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
  • yet it doesn’t work!

Can anyone help?!

It’s late now, so I might leave to the morning:
Can you confirm that this is the current position?

Hi @unman

Yes, that is the state of play at the moment.

Thanks!

I have a backup cronjob that I’m trying to implement.
And then I’m wondering if it’s possible to run qvm-copy automatically? Without a pop-up window.
I realise that currently I have to return to my screen and type in the VM name when away, and that it could interrupt my workflow if I happen to be working at that time.
First time doing something like this, so probably some stuff I could improve upon.

Crontab:
0 5 * * 1 ~/.rc/back
Run at 5 am every week

Backup script:

cp ~/db.kdbx ~/db_`date +\%d\%m\%Y`.kdbx
qvm-copy db_`date +\%d\%m\%Y`.kdbx
rm db_`date +\%d\%m\%Y`.kdbx

This will copy from my airgapped VM where the database will be unlocked and modified.
I always make a new file name because qvm-copy fails if the same file already exists on the destination VM.

From there I use nextcloudcmd to sync with the server.

@9009

Is cron working for you in the AppVm or are you using the Dom0 Cron (which I think you are)?

Yes, it is possible. You just need to change the qrexe policy file in /etc/qubes-rpc/policy/qubes.Filecopy and add:

[src_vm] [target_vm] allow

where [src_vm] is the VM where you want to copy the files to and [target_vm] the one you want to copy them to.

But I encourage you to read the documentation on Qubes RPC Policies Files as changing them has security implications:

1 Like

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

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

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.

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

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

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.

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?

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

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

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

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.

My bad!

Not your fault - blame the forum format.

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.