-
Notifications
You must be signed in to change notification settings - Fork 94
APT's cron file missing #9
Comments
Thanks for the report Callum! This is indeed strange, maybe there is some postinstall configuration required. Could you please specify what distribution and version do you use (and whether you recently did dist-upgrade)? I'd like to check the source package. |
It's Ubuntu 14.04 from owned-networks.net. I have a handful of other 14.04 machines and they have apt's cron file enabled by default. I read somewhere that maybe cheap VPS providers disable a load of stuff in cron.daily to save CPU cycles! :-) It seems like it's an unlikely scenario, not sure if it really makes sense to include a test in the role or not. I added my own test to the playbook to rename the file from |
I see, this was also reported in here: http://askubuntu.com/questions/530133/cron-jobs-are-disabled-on-clean-installation-of-14-04 I wonder how the provider makes this change: either they provide a modified package through a mirror (which seems unlikely), or it is already in the image – as a preinstalled file, a file diversion or as a separate process which renames these files. Anyway I don't think we should attempt to fix this edge case through this role. I'd recommend to create a new role for renaming the file which might depend on this role for easier updates and reusability. And also question your provider about their decisions. Moving the file should be a two phase process, e.g.: - name: check if apt.disabled exists
stat: path=/etc/cron.daily/apt.disabled
register: apt_disabled
- name: reenable apt script for daily cron
command: mv /etc/cron.daily/apt.disabled /etc/cron.daily/apt
when: apt_disabled.stat.exists (see stat module) I will close this issue, let me know if this is okay. |
Ah yes, check if the |
Oh, and sure, I can see that it doesn't make sense to check for this particular edge case in a generic module. Thanks for the feedback and for saving me a load of time by publishing your module. 👍 |
@jnv This doesn't seem to be so rare. I ran into the same thing today.
I guess the provider does this change in their system image they then install on their customers servers. However, I wonder why I agree with your point about keeping this role as small as possible, but in this case, it seems as if it would probably make sense to add it, as it apparantly happens quite regularly. Btw, this is not a cheap VPS but a quite expensive one with the big german hosting company Strato. |
I created a role which deals with this: https://github.com/Yannik/ansible-role-enable-standard-cronjobs |
@Yannik Thanks! |
Hi guys, I have just stubled across the same issue. Lots of *.disabled files. So to make this conversation complete, here are my 5 cents. By installing debsums and running
you can find all the files that were either changed/moved/deleted. And here is the answer how to get them back And I would really like to know how renamed them... Cheers! |
Not sure it's really an issue with this role, maybe more the host system, but I'll post it here anyway.
I have 2 systems where
/etc/cron.daily/apt
does not exist and is instead called/etc/cron.daily/apt.disabled
. In this situation, the unattended-upgrades package does not get run.Maybe there could be a check in this role to make sure that the necessary cron files exist? I'm not sure if they are standard across distributions though, so understand if it's not practical.
The text was updated successfully, but these errors were encountered: