patchman
patchman copied to clipboard
furlongm
packages.models.MultipleObjectsReturned: get() returned more than one PackageUpdate
I get the following traceback when trying to update one particular host, other hosts work OK.
[root@patchman ~]# patchman -A -H host.example.com
Finding updates for Host host.example.com
host.example.com
acl-2.2.51-14.el7-x86_64 -> acl-2.2.51-15.el7-x86_64 (Bugfix)
atk-2.28.1-1.el7-x86_64 -> atk-2.28.1-2.el7-x86_64 (Bugfix)
Traceback (most recent call last):
File "/usr/bin/patchman", line 687, in <module>
main()
File "/usr/bin/patchman", line 681, in main
showhelp = process_args(args)
File "/usr/bin/patchman", line 655, in process_args
host_updates_alt(args.host)
File "/usr/bin/patchman", line 283, in host_updates_alt
host.find_updates()
File "/usr/lib/python3.6/site-packages/hosts/models.py", line 216, in find_updates
repo_packages)
File "/usr/lib/python3.6/site-packages/hosts/models.py", line 265, in find_host_repo_updates
uid = self.process_update(package, highest_package)
File "/usr/lib/python3.6/site-packages/hosts/models.py", line 160, in process_update
newpackage=highest_package
File "/usr/lib/python3.6/site-packages/django/db/models/query.py", line 412, in get
(self.model._meta.object_name, num)
packages.models.MultipleObjectsReturned: get() returned more than one PackageUpdate -- it returned 2!
[root@patchman ~]# rpm -q patchman
patchman-2.0.1-1.noarch
Is it possible to enable debug or similar to see what happens?
Thanks for the patch! But the test case is unfortunately gone after some OS updates. I will test it out if the test case reappears.
Can you add the code in 927f5b3 to help debug the issue?
I have the same issue with the most recent version of Patchman. After adding that code I'm getting the following:
Traceback (most recent call last):
File "/usr/bin/patchman", line 30, in <module>
django_setup()
File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup
apps.populate(settings.INSTALLED_APPS)
File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 114, in populate
app_config.import_models()
File "/usr/lib/python3/dist-packages/django/apps/config.py", line 211, in import_models
self.models_module = import_module(models_module_name)
File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 790, in exec_module
File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/hosts/models.py", line 29, in <module>
from packages.models import Package, PackageUpdate, MultipleObjectsReturned
ImportError: cannot import name 'MultipleObjectsReturned' from 'packages.models' (/usr/lib/python3/dist-packages/packages/models.py)
Can you add the code in 927f5b3 to help debug the issue?
I have the same issue with the most recent version of Patchman. After adding that code I'm getting the following:
Traceback (most recent call last): File "/usr/bin/patchman", line 30, in <module> django_setup() File "/usr/lib/python3/dist-packages/django/__init__.py", line 24, in setup apps.populate(settings.INSTALLED_APPS) File "/usr/lib/python3/dist-packages/django/apps/registry.py", line 114, in populate app_config.import_models() File "/usr/lib/python3/dist-packages/django/apps/config.py", line 211, in import_models self.models_module = import_module(models_module_name) File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1030, in _gcd_import File "<frozen importlib._bootstrap>", line 1007, in _find_and_load File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked File "<frozen importlib._bootstrap>", line 680, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 790, in exec_module File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed File "/usr/lib/python3/dist-packages/hosts/models.py", line 29, in <module> from packages.models import Package, PackageUpdate, MultipleObjectsReturned ImportError: cannot import name 'MultipleObjectsReturned' from 'packages.models' (/usr/lib/python3/dist-packages/packages/models.py)
You must add
from django.core.exceptions import MultipleObjectsReturned
instead of appending
from packages.models import Package, PackageUpdate, MultipleObjectsReturned
Yes, I just ran it after correcting debug :
bash-4.1.2-33.el6-x86_64 -> bash-4.1.2-48.el6-x86_64 (Bugfix)
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/hosts/models.py", line 159, in process_update
update = updates.get(
File "/usr/lib/python3/dist-packages/django/db/models/query.py", line 410, in get
raise self.model.MultipleObjectsReturned(
packages.models.MultipleObjectsReturned: get() returned more than one PackageUpdate -- it returned 2!
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/patchman", line 686, in <module>
main()
File "/usr/bin/patchman", line 680, in main
showhelp = process_args(args)
File "/usr/bin/patchman", line 654, in process_args
host_updates_alt(args.host)
File "/usr/bin/patchman", line 283, in host_updates_alt
host.find_updates()
File "/usr/lib/python3/dist-packages/hosts/models.py", line 231, in find_updates
update_ids = self.find_host_repo_updates(host_packages,
File "/usr/lib/python3/dist-packages/hosts/models.py", line 281, in find_host_repo_updates
uid = self.process_update(package, highest_package)
File "/usr/lib/python3/dist-packages/hosts/models.py", line 172, in process_update
sys.exit(1)
NameError: name 'sys' is not defined
Seems to come from added debugging code Added "import sys" at the beginning of file, and running again
After adding "import sys", now script just stop cleanly without saying anything - no traceback at all :/
Updated in 71eaaf4
After adding "import sys", now script just stop cleanly without saying anything - no traceback at all :/
That is very odd. Added a bit more debug info so we can see what package is affected.
This issue appeared on a server impacted by https://github.com/furlongm/patchman/issues/324
Updated in 71eaaf4
After adding "import sys", now script just stop cleanly without saying anything - no traceback at all :/
That is very odd. Added a bit more debug info so we can see what package is affected.
Now it ends like this :
autofs-1:5.0.5-113.el6-x86_64 -> autofs-1:5.0.5-140.el6_10.1-x86_64 (Bugfix)
avahi-libs-0.6.25-15.el6-x86_64 -> avahi-libs-0.6.25-17.el6-x86_64 (Bugfix)
MultipleObjectsReturned with oldpackage=bash-4.1.2-33.el6-x86_64 | newpackage=bash-4.1.2-48.el6-x86_64:
bash-4.1.2-33.el6-x86_64 -> bash-4.1.2-48.el6-x86_64 (Bugfix)
#
Maybe a hidden space or character ?
I removed sys.exit(1) and let it run Issue is occuring frequently, on RedHat servers, for example :
MultipleObjectsReturned with oldpackage=vim-common-2:7.4.629-5.el6-x86_64 | newpackage=vim-common-2:7.4.629-5.el6_10.2-x86_64:
vim-common-2:7.4.629-5.el6-x86_64 -> vim-common-2:7.4.629-5.el6_10.2-x86_64 (Bugfix)
vim-common-2:7.4.629-5.el6-x86_64 -> vim-common-2:7.4.629-5.el6_10.2-x86_64 (Security)
vim-common-2:7.4.629-5.el6-x86_64 -> vim-common-2:7.4.629-5.el6_10.2-x86_64 (Security)
MultipleObjectsReturned with oldpackage=vim-enhanced-2:7.4.629-5.el6-x86_64 | newpackage=vim-enhanced-2:7.4.629-5.el6_10.2-x86_64:
vim-enhanced-2:7.4.629-5.el6-x86_64 -> vim-enhanced-2:7.4.629-5.el6_10.2-x86_64 (Bugfix)
vim-enhanced-2:7.4.629-5.el6-x86_64 -> vim-enhanced-2:7.4.629-5.el6_10.2-x86_64 (Security)
vim-enhanced-2:7.4.629-5.el6-x86_64 -> vim-enhanced-2:7.4.629-5.el6_10.2-x86_64 (Security)
MultipleObjectsReturned with oldpackage=vim-filesystem-2:7.4.629-5.el6-x86_64 | newpackage=vim-filesystem-2:7.4.629-5.el6_10.2-x86_64:
vim-filesystem-2:7.4.629-5.el6-x86_64 -> vim-filesystem-2:7.4.629-5.el6_10.2-x86_64 (Bugfix)
vim-filesystem-2:7.4.629-5.el6-x86_64 -> vim-filesystem-2:7.4.629-5.el6_10.2-x86_64 (Security)
vim-filesystem-2:7.4.629-5.el6-x86_64 -> vim-filesystem-2:7.4.629-5.el6_10.2-x86_64 (Security)
MultipleObjectsReturned with oldpackage=vim-minimal-2:7.4.629-5.el6-x86_64 | newpackage=vim-minimal-2:7.4.629-5.el6_10.2-x86_64:
vim-minimal-2:7.4.629-5.el6-x86_64 -> vim-minimal-2:7.4.629-5.el6_10.2-x86_64 (Bugfix)
vim-minimal-2:7.4.629-5.el6-x86_64 -> vim-minimal-2:7.4.629-5.el6_10.2-x86_64 (Security)
vim-minimal-2:7.4.629-5.el6-x86_64 -> vim-minimal-2:7.4.629-5.el6_10.2-x86_64 (Security)
> MultipleObjectsReturned with oldpackage=vim-minimal-2:7.4.629-5.el6-x86_64 | newpackage=vim-minimal-2:7.4.629-5.el6_10.2-x86_64:
> vim-minimal-2:7.4.629-5.el6-x86_64 -> vim-minimal-2:7.4.629-5.el6_10.2-x86_64 (Bugfix)
> vim-minimal-2:7.4.629-5.el6-x86_64 -> vim-minimal-2:7.4.629-5.el6_10.2-x86_64 (Security)
> vim-minimal-2:7.4.629-5.el6-x86_64 -> vim-minimal-2:7.4.629-5.el6_10.2-x86_64 (Security)
Definitely multiple objects returned here. 2 security and one bugfix for the same update. There should not be a security and bugfix update for the same update and there should not be 2 identical security updates. Trying to figure out how this happened.
Also wondering if patchman -d helps clean these up?
Looks like patchman -d did the trick
I compared outputs from before and after duplicate cleaning :
audit-libs-2.3.7-5.el6-x86_64 -> audit-libs-2.4.5-6.el6-x86_64 (Bugfix)
autofs-1:5.0.5-113.el6-x86_64 -> autofs-1:5.0.5-140.el6_10.1-x86_64 (Bugfix)
avahi-libs-0.6.25-15.el6-x86_64 -> avahi-libs-0.6.25-17.el6-x86_64 (Bugfix)
-MultipleObjectsReturned with oldpackage=bash-4.1.2-33.el6-x86_64 | newpackage=bash-4.1.2-48.el6-x86_64:
-bash-4.1.2-33.el6-x86_64 -> bash-4.1.2-48.el6-x86_64 (Bugfix)
bash-4.1.2-33.el6-x86_64 -> bash-4.1.2-48.el6-x86_64 (Security)
-bash-4.1.2-33.el6-x86_64 -> bash-4.1.2-48.el6-x86_64 (Security)
-MultipleObjectsReturned with oldpackage=bind-libs-32:9.8.2-0.37.rc1.el6-x86_64 | newpackage=bind-libs-32:9.8.2-0.68.rc1.el6_10.8-x86_64:
-bind-libs-32:9.8.2-0.37.rc1.el6-x86_64 -> bind-libs-32:9.8.2-0.68.rc1.el6_10.8-x86_64 (Bugfix)
-bind-libs-32:9.8.2-0.37.rc1.el6-x86_64 -> bind-libs-32:9.8.2-0.68.rc1.el6_10.8-x86_64 (Security)
bind-libs-32:9.8.2-0.37.rc1.el6-x86_64 -> bind-libs-32:9.8.2-0.68.rc1.el6_10.8-x86_64 (Security)
-MultipleObjectsReturned with oldpackage=bind-utils-32:9.8.2-0.37.rc1.el6-x86_64 | newpackage=bind-utils-32:9.8.2-0.68.rc1.el6_10.8-x86_64:
-bind-utils-32:9.8.2-0.37.rc1.el6-x86_64 -> bind-utils-32:9.8.2-0.68.rc1.el6_10.8-x86_64 (Bugfix)
-bind-utils-32:9.8.2-0.37.rc1.el6-x86_64 -> bind-utils-32:9.8.2-0.68.rc1.el6_10.8-x86_64 (Security)
bind-utils-32:9.8.2-0.37.rc1.el6-x86_64 -> bind-utils-32:9.8.2-0.68.rc1.el6_10.8-x86_64 (Security)
binutils-2.20.51.0.2-5.43.el6-x86_64 -> binutils-2.20.51.0.2-5.48.el6_10.1-x86_64 (Bugfix)
biosdevname-0.6.2-1.el6-x86_64 -> biosdevname-0.7.2-1.el6-x86_64 (Bugfix)
Thank you @furlongm ! And many thanks for creating patchman, great tool !
Maybe I need to add a message here recommending a workaround of patchman -d.
I thought the daily cronjob with patchman -a should handle that, but maybe it's not working, or the issue keeps coming back?
An order problem then ? -d should be executed before the rest
I'll run a -a to see if issue comes back
@julienleboeuf out of curiousity - do you specify the -u option to patchman-client?
Since forcing a database clean with -d, issue didn't occured again.
I tried -u option on client too, no change
Closing as issue has not recurred. Feel free to reopen if it does, and we can investigate further.