crond never starts in AppVMs

[marmarek]

Reported by cprise on 28 Oct 2014 11:33 UTC
The crond.service is never started when an AppVM boots up, and changing its status to 'enabled' with systemctl in the templateVM has no effect.

I haven't yet tested this with regular Fedora; Thinking it may be some side-effect of the way Qubes uses systemd.

See discussion https://groups.google.com/forum/#!topic/qubes-users/vVw1kZ1ph_A

Migrated-From: https://wiki.qubes-os.org/ticket/909

[marmarek]

Comment by anonymous on 28 Oct 2014 21:49 UTC
The other discussion critical to this issue is here:
https://groups.google.com/forum/#!searchin/qubes-users/persistence$20in$20appvm/qubes-users/7DzdDDXFbso/hQs1o1RXYHkJ

I had to make /var/spool a symlink to a folder in /rw because cron and especially anacron need to keep track of activity across reboots.

I am guessing that systemd runs crond.service before /rw gets mounted (see below...). Any way to fix this?

$ sudo systemctl status crond.service
crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled)
Active: failed (Result: exit-code) since Tue 2014-10-28 07:13:10 EDT; 4h 42min ago
Main PID: 709 (code=exited, status=1/FAILURE)

Oct 28 07:13:10 fedora-20-MM systemd[Started Command Scheduler.
Oct 28 07:13:10 fedora-20-MM crond709: /var/spool/cron: No such file or directory
Oct 28 07:13:10 fedora-20-MM crond[/var/spool/cron: mkdir: No such file or directory
Oct 28 07:13:10 fedora-20-MM systemd1: crond.service: main process exited, code=exited, status=...LURE
Oct 28 07:13:10 fedora-20-MM systemd[1]: Unit crond.service entered failed state.

[marmarek]

Modified by marmarek on 3 Nov 2014 20:52 UTC

[marmarek]

Modified by marmarek on 13 Jan 2015 23:42 UTC

[marmarek]

Modified by marmarek on 14 Jan 2015 02:22 UTC

[marmarek]

Comment by marmarek on 27 Jan 2015 00:19 UTC
http://git.qubes-os.org/?p=marmarek/core-agent-linux.git;a=commit;h=24c74c44e842c5e363d8d5f444abe0b4e608e763

[marmarek]

Comment by marmarek on 27 Jan 2015 00:19 UTC
Now the service can be enabled by 'crond' qvm-service.

[adrelanos]

Could you please explain the rationale behind why crond does not run by default in any VM?

[marmarek]

In most cases none of crond started scripts makes sense in AppVM because changes in root filesystem are discarded. Like updatedb, mandb, prelink etc. And in most cases are harmful for performance (imagine 10 AppVMs running updatedb at the same time).
So instead of manually disabling dozen of them, disable cron as the whole, allowing to enable it if someone really needs.
Systemd timers are not affected by this.

[adrelanos]

Makes sense. Thank you!

What about anacron? Would not the same apply to it?

[marmarek]

What about anacron? Would not the same apply to it?

Yes, exactly. But it is started from crond (in cron.hourly), so both are covered.

[adrelanos]

Are you sure anacron is not called from other places also?

apt-file list anacron

Relevant excerpt.

anacron: /etc/init.d/anacron
anacron: /etc/init/anacron.conf

anacron: /lib/systemd/system/anacron-resume.service
anacron: /lib/systemd/system/anacron.service
anacron: /usr/lib/pm-utils/power.d/anacron
anacron: /usr/lib/pm-utils/sleep.d/95anacron

I've just installed the anacron package and checked 'sudo service
anacron status' - and it's running announcing to run /etc/cron[...].

[marmarek]

Ah, so my comment applies only to Fedora then. I think it would be good idea to start in conditionally on crond qvm-service (similar to Fedora) and add to crond description in qvm-service. Any reason to give it a separate entry?

[adrelanos]

Would you like to reopen or do you prefer me to open a new ticket?

Any reason to give it a separate entry?

Not that I can see. I think for such highly special needs, the user should set it up that way manually and we should keep the default simple. A single entry.

[marmarek]

Would you like to reopen or do you prefer me to open a new ticket?

Since this was for R2.0, better new one.

[adrelanos]

Created #2109 for it.