Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upUse bind-dirs to handle crontab persistence #2327
Comments
andrewdavidwong
added
bug
C: Debian
labels
Sep 19, 2016
andrewdavidwong
added this to the Release 3.2 milestone
Sep 19, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
jbwells
Oct 2, 2016
I forgot to mention: This problem also mean that you can not configure cron jobs in the TemplateVM that will run in AppVMs based on it.
jbwells
commented
Oct 2, 2016
|
I forgot to mention: This problem also mean that you can not configure cron jobs in the TemplateVM that will run in AppVMs based on it. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
unman
Oct 8, 2016
Member
This isn't a Debian specific issue, and I'm not convinced it's a bug - it's a feature of the normal Qubes treatment of template based qubes. The statement of expected behaviour seems to me to be inappropriate for Qubes.
The use of /rw/cron enables something approaching a standard use of cron. Since a standard crontab file would disappear on reboot, the /rw/cron files enable cron jobs to persist for a template based qube.
It is possible to configure cron jobs in a Template, using the /rw/cron mechanism, and they will run in any qube created using that template. Like changes in /home, later editing of files on the template will not feed through to the qube after it has been created.
|
This isn't a Debian specific issue, and I'm not convinced it's a bug - it's a feature of the normal Qubes treatment of template based qubes. The statement of expected behaviour seems to me to be inappropriate for Qubes. It is possible to configure cron jobs in a Template, using the /rw/cron mechanism, and they will run in any qube created using that template. Like changes in /home, later editing of files on the template will not feed through to the qube after it has been created. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Oct 9, 2016
Member
I can see the arguments on both sides. Ultimately, this may be more of a feature request than a bug report. @marmarek?
|
I can see the arguments on both sides. Ultimately, this may be more of a feature request than a bug report. @marmarek? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Oct 9, 2016
Member
Since we have bind-dirs, it should be quite easy to move that cron handling
|
Since we have bind-dirs, it should be quite easy to move that cron handling |
andrewdavidwong
changed the title from
crontab created while cron service is stopped is hidden when cron service is started
to
Use bind-dirs to handle crontab persistence
Oct 9, 2016
andrewdavidwong
added
enhancement
and removed
bug
labels
Oct 9, 2016
This was referenced Oct 11, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Oct 11, 2016
Member
@marmarek QubesOS/qubes-doc#199 (comment)
I think it would be better to package bind-dirs configuration for cron, as part of QubesOS/qubes-core-agent-linux#19, instead of relying on user to manually do it.
|
@marmarek QubesOS/qubes-doc#199 (comment)
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
It's done. |
jbwells commentedSep 19, 2016
Qubes OS version (e.g.,
R3.1):R3.2-rc2
Affected TemplateVMs (e.g.,
fedora-23, if applicable):AppVM using debian-8 TemplateVM
Expected behavior:
Whenever cron is running, it should obey a crontab installed via the crontab program. It should also be possible to remove a crontab while cron is not running.
Actual behavior:
Crontab files installed while cron is not running are hidden by a directory mounted over them when cron is started.
Steps to reproduce the behavior:
sudo systemctl stop cron
crontab FILE
sudo systemctl start cron
General notes:
See /lib/systemd/system/cron.service.d/30_qubes.conf.
This is very confusing when trying to debug why your cron jobs are not running!
Related issues: