apt module: update_cache=yes does nothing

[Bengrunt]

Hello,
I was trying to use the update_cache feature of the apt module to run apt-get update without installing a package. So I've got this basic task:

- name: Updating APT cache
   apt: update_cache=yes

When the task runs, it says 'ok' but the cache isn't updated at all.
There seem to be the same behavior if update_cache=yes is added with an actual package installation.

I'm using ansible v1.9.1 on CentOS 7 to manage hosts running Ubuntu 14.04LTS.

[cloudnull]

Bump, this issue looks like it effects all current v1.9.x versions including v1.9.2-0.1.rc1:

• ansible-modules-core/packaging/os/apt.py

  Lines 558 to 589 in 016ad8a

  	if p['update_cache']:
  	# Default is: always update the cache
  	cache_valid = False
  	if p['cache_valid_time']:
  	tdelta = datetime.timedelta(seconds=p['cache_valid_time'])
  	try:
  	mtime = os.stat(APT_UPDATE_SUCCESS_STAMP_PATH).st_mtime
  	except:
  	mtime = False
  	if mtime is False:
  	# Looks like the update-success-stamp is not available
  	# Fallback: Checking the mtime of the lists
  	try:
  	mtime = os.stat(APT_LISTS_PATH).st_mtime
  	except:
  	mtime = False
  	if mtime is False:
  	# No mtime could be read - looks like lists are not there
  	# We update the cache to be safe
  	cache_valid = False
  	else:
  	mtimestamp = datetime.datetime.fromtimestamp(mtime)
  	if mtimestamp + tdelta >= datetime.datetime.now():
  	# dont update the cache
  	# the old cache is less than cache_valid_time seconds old - so still valid
  	cache_valid = True
  	if cache_valid is not True:
  	cache.update()
  	cache.open(progress=None)
  	if not p['package'] and not p['upgrade'] and not p['deb']:
  	module.exit_json(changed=False)

• ansible-modules-core/packaging/os/apt.py

  Lines 558 to 589 in d56c219

  	if p['update_cache']:
  	# Default is: always update the cache
  	cache_valid = False
  	if p['cache_valid_time']:
  	tdelta = datetime.timedelta(seconds=p['cache_valid_time'])
  	try:
  	mtime = os.stat(APT_UPDATE_SUCCESS_STAMP_PATH).st_mtime
  	except:
  	mtime = False
  	if mtime is False:
  	# Looks like the update-success-stamp is not available
  	# Fallback: Checking the mtime of the lists
  	try:
  	mtime = os.stat(APT_LISTS_PATH).st_mtime
  	except:
  	mtime = False
  	if mtime is False:
  	# No mtime could be read - looks like lists are not there
  	# We update the cache to be safe
  	cache_valid = False
  	else:
  	mtimestamp = datetime.datetime.fromtimestamp(mtime)
  	if mtimestamp + tdelta >= datetime.datetime.now():
  	# dont update the cache
  	# the old cache is less than cache_valid_time seconds old - so still valid
  	cache_valid = True
  	if cache_valid is not True:
  	cache.update()
  	cache.open(progress=None)
  	if not p['package'] and not p['upgrade'] and not p['deb']:
  	module.exit_json(changed=False)

[Bengrunt]

Hey there,

Thanks for the fix :) 👍

Could be nice to also add the default value for cache_valid_time in the docs. Was wondering what it was when trying to use it earlier.

[cloudnull]

@Bengrunt I updated the PR to now document that the cache_valid_time is 0 by default.

[Bengrunt]

Awesome :)
I think it's gonna help a lot of people.

[wysekm]

Hi,

I have a similar problem in Ansible 1.9.3. When I start a fresh instance in AWS EC2 and try to install packages (Ubuntu 14.04) using:

- name: Install packages
    apt: pkg={{item}} state=present update_cache=True
    with_items:
    - python-virtualenv
    ...

It always fails on the first try with saying:

msg: No package matching 'python-virtualenv' is available

When I start that playbook the second time from that task it succeeds. If I run:

- name: Manually update packages list
    apt: update_caches=True

it does nothing and the package list is not refreshed. The only scenario when refreshing packages works on the first try is when I run it explicitly:

- name: Manually update packages list (problem with update_cache)
    command: apt-get update

[cloudnull]

@wysekm if you don't mind pulling in a patch, this change fixed the issue for us #1517 -- it's currently a pending PR to core.

[FlorinAndrei]

Same issue with 1.9.4, running on Mac, with Ubuntu 14.04 instances