When no disk space is left, os_patching reports no patches to apply rather than an error

[rnelson0]

I have a server that has no free space on the partition the yum database is kept on:

[root@server ~]# facter -p os_patching
{
  package_updates => [],
  package_update_count => 0,
  security_package_updates => [],
  security_package_update_count => 0,
  blocked => false,
  blocked_reasons => [],
  blackouts => {
    End of year 2018 change freeze => {
      start => "2018-12-15T00:00:00+1000",
      end => "2019-01-05T23:59:59+1000"
    },
    End of year 2019 change freeze => {
      start => "2019-12-15T00:00:00+1000",
      end => "2020-01-05T23:59:59+1000"
    },
    End of year 2020 change freeze => {
      start => "2020-12-15T00:00:00+1000",
      end => "2021-01-05T23:59:59+1000"
    },
    End of year 2021 change freeze => {
      start => "2021-12-15T00:00:00+1000",
      end => "2022-01-05T23:59:59+1000"
    }
  },
  pinned_packages => [],
  last_run => {},
  patch_window => "trustwave",
  reboots => {
    reboot_required => true,
    apps_needing_restart => {
      3472 => "/opt/puppetlabs/puppet/bin/pxp-agent",
      2602 => "/opt/puppetlabs/puppet/bin/pxp-agent"
    },
    app_restart_required => true
  }
}

[root@server ~]# yum update
Loaded plugins: product-id, search-disabled-repos, security, subscription-manager
[Errno 28] No space left on device
Traceback (most recent call last):
  File "/usr/bin/yum", line 29, in <module>
    yummain.user_main(sys.argv[1:], exit_code=True)
  File "/usr/share/yum-cli/yummain.py", line 298, in user_main
    errcode = main(args)
  File "/usr/share/yum-cli/yummain.py", line 124, in main
    base.doLock()
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 1851, in doLock
    while not self._lock(lockfile, mypid, 0644):
  File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 1921, in _lock
    os.write(fd, contents)
OSError: [Errno 28] No space left on device

[root@server ~]# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_application-lv_root
                      9.0G  3.8G  4.8G  44% /
tmpfs                 7.8G     0  7.8G   0% /dev/shm
/dev/sda1             477M  115M  337M  26% /boot
/dev/mapper/vg_application-lv_newvar
                      591G  591G     0 100% /var

Once the partition is cleaned up, os_patching facts populate fully:

[root@server ~]# /usr/local/bin/os_patching_fact_generation.sh
[root@server ~]# facter -p os_patching
{
  package_updates => [
    "abrt.x86_64",
    "abrt-addon-ccpp.x86_64",
    "abrt-addon-kerneloops.x86_64",
    "abrt-addon-python.x86_64",
    "abrt-cli.x86_64",
    "abrt-libs.x86_64",
    "abrt-python.x86_64",
    "abrt-tui.x86_64",
    "autofs.x86_64",
...

I would expect that if the disk were full, or yum was otherwise unable to generate results, that the fact would indicate an unavailability of data, rather than indicating a patched server.

[albatrossflavour]

Good catch. How about we add in an array in the fact for error/debug information. Updating the package list to be something other than a list (same with the count) could break automated parsing, but having a separate area for debugging and error reporting would be useful.

Something like

facter -p os_patching
{
  package_updates => [],
  package_update_count => 0,
  security_package_updates => [],
  security_package_update_count => 0,
  blocked => false,
  errors => [
      "No update file found, package update information invalid",
  ]
}

[albatrossflavour]

I've created a branch which includes this functionality now:

root@puppetmaster os_patching # facter -p os_patching.warnings
{}
root@puppetmaster os_patching # touch -t 08060000 -m ./package_updates
root@puppetmaster os_patching # facter -p os_patching.warnings
{
  update_file_time => "Update file has not been updated in 10 days"
}
root@puppetmaster os_patching # rm package_updates
root@puppetmaster os_patching # facter -p os_patching.warnings
{
  update_file => "Update file not found, update information invalid"
}
root@puppetmaster os_patching # facter -p os_patching.warnings
{
  update_file => "Update file not found, update information invalid",
  security_update_file => "Security update file not found, update information invalid"
}

[albatrossflavour]

Fixed in PR 43