New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.327 was not provided by any .service files #570
Comments
|
This is definitely a new one! Thanks for the clear report. Exception: |
|
Have you noticed if that ":1.435" name varies across runs? I haven't touched DBUS in a while, so wondering if the '435' is maybe a PID |
|
This seems to work fine with 2.7.9 against CentOS 7, I'll need to grab a 7.5 VM to try again. I doubt it's relevant, but does your service XML use any fancy firewalld modules etc? This looks like a DBUS configuration error (clearly), so probably it's not related to the contents of your config at all |
|
https://github.com/firewalld/firewalld/blob/v0.5.3/src/firewall/client.py appears to be the version shipped with 7.5 |
|
multiple suggestions (here: http://gnome-evolution-general.1774414.n4.nabble.com/The-name-1-157-was-not-provided-by-any-service-files-td4668022.html#a4668037 and flatpak/flatpak#1845 here) the error might relate to the backing service going away somehow |
|
@dw The |
Service files are pretty basic: |
|
Also, changing |
|
I haven't figured out what's broken yet (haven't reproduced yet either!), but the rough guess is that the glib dbus client in the persistent interpreter is being broken somehow. I notice some ugly looking initialization code, it's possible it's being partially reinitialized twice, or similar. This stuff has a fairly mature design, so whatever the problem I'm pretty sure the fix will be straightforwrad :) |
That is the file present on my installation of Centos 7.5 |
|
Reproduced it.. doesn't happen on first module invocation, but on second. So there is some shared component that is getting trashed somehow |
|
Hah! Real stupid bug. We restart firewalld, but keep a copy of the old firewall client around, which knows firewalld by a different name -- that ":1:123" crap is a needlessly cryptic unique name generated by dbus on initial connection by any app. So on second invocation, the cached client tries to talk to a dbus client that no longer exists. Should be an easy fix, but for the time being, you can simply run the firewalld in isolated mode: - name: Enable custom service
firewalld:
service: foo
permanent: true
immediate: true
state: enabled
vars:
mitogen_task_isolation: fork
|
issue #570: add firewalld to always-fork list for now.
|
Thanks for the help @dw |
* origin/v027: docs: update Changelog for release. Bump version for release. issue #587: update Changelog issue #587: ansible: descriptive version check during startup. ansible: descriptive version check during startup. issue #581: expose mitogen_mask_remote_name variable. issue #576: fix Kwargs minor version check. issue #574: fix ISSUE_TEMPLATE link issue #575: fix exception text rendering docs: remove infringing mark docs: fix config var scope docs: faster stats-preserving redirect docs: update ansible page issue #570: add firewalld to always-fork list for now. docs: removed excess word docs: fixed message routing example description docs: removed repeated word docs: update Changelog; closes #557. issue #557: support correct cpu_set_t size
|
This was released as part of 0.2.7. Thanks again |
Ansible Version: 2.7.5 (tried 2.7.9 as well)
Ansible Patched: No
Custom Modules: Yes (albeit not likely related to issue)
Have you tried the latest master version from Git?: No
Host and Target Python Versions: 2.7.5
Target OS: CentOS 7.5.1804 (Core)
Base error message:
verbose-log-output-dbus-exception.txt
Ansible Config Dump:
So this error has been occurring when we try to enable a service after restarting firewalld. Reload comes back as changed, going to the enable custom service task and bombs out. This is the task order with the last throwing the error:
The text was updated successfully, but these errors were encountered: