Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 876683 - RFE: make firewalld be a dbus activated service that exits after a period of inactivity
Summary: RFE: make firewalld be a dbus activated service that exits after a period of ...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Eric Garver
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker IoT
TreeView+ depends on / blocked
 
Reported: 2012-11-14 17:32 UTC by Matthew Miller
Modified: 2019-01-07 14:12 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github firewalld firewalld issues 337 0 None open Make firewalld dbus activatable 2020-02-21 15:06:41 UTC

Description Matthew Miller 2012-11-14 17:32:45 UTC 
This is a long-term RFE rather than something immediate, but I think it'll make Firewalld more broadly applicable to many use cases, and reduce resistance to uptake, so I'd like to see it on the future roadmap. I understand that there's some complexity involved.

In short:

Firewalld should migrate from being an always-running service to being system-activated when changes are needed and exiting after current work has completed.

This has two primary benefits:

1) In static use cases, the firewall never changes, so having a daemon running is a waste of resources. In most cases where dynamic changes *are* required, these changes are infrequent, and so again the always-running daemon is not useful.

2) Code that is started when needed and which _expects_ to go away exercises the startup/shutdown paths constantly and so is inherently more robust.


Firewalld *already* uses DBus, so this seems like a natural fit.

The service could exit after a certain timeout, so that if a large number of requests are coming in, they could all be handled without restart.
Comment 1 Matthew Miller 2012-11-21 13:43:39 UTC 
See comments from Lennart Poettering on how to implement dbus activation with systemd here:

http://www.mail-archive.com/devel@lists.fedoraproject.org/msg50875.html
Comment 2 Thomas Woerner 2012-11-21 15:21:37 UTC 
This needs some verification work to make sure that a mechanism like this is usable at all times and does not result in other problems like for example message timeouts for requests if the timeout of a request is shorter than the start time of the daemon using dbus activation.
Comment 3 Colin Walters 2012-12-13 01:08:13 UTC 
See https://bugs.freedesktop.org/show_bug.cgi?id=11454
Comment 4 Thomas Woerner 2015-07-20 11:38:22 UTC 
The results of the D-Bus activation tests with firewalld are:

The mechanisms is working, but firewalld will not suspend as long as a consumer of the D-Bus interface of firewalld is active. To be more pecise: As long as there is a signal receiver for the firewalld D-Bus interface, firewalld will not suspend. This is the case for NetworkManager, firewall-applet and also firewall-config. The will most likely also be the case with configuration using a Cockpit plugin.

Result: This feature is of limited use is most environments.
Comment 5 Matthew Miller 2015-07-20 14:42:02 UTC 
> Result: This feature is of limited use is most environments.

What about in the case of a cloud server running NetworkManager in config-and-exit mode (or using systemd-networkd for network config)?

You say it's _likely_ that a Cockpit plugin would keep firewalld persistent; could it be carefully written so it doesn't?
Comment 6 Thomas Woerner 2015-08-31 15:00:53 UTC 
As far as I know it is not possible to have a Cockpit plugin that is not keeping a D-Bus server in a persistent state. As soon as there is a signal receiver there is a consumer and the service should not suspend.
Comment 7 Thomas Woerner 2015-09-01 07:58:35 UTC 
I did some more tests and it seems that this is not an issue nowadays anymore. I only notified issues by switching from one dbus implementation to another one. For example by switching from python-dbus to gdbus.

I will open a ticket for python-slip for deeper investigation.
Comment 8 Thomas Woerner 2015-09-01 08:22:51 UTC 
Here is the submitted issue for python-slip: https://github.com/nphilipp/python-slip/issues/2
Comment 9 Peter Robinson 2019-01-03 01:25:38 UTC 
Bump, any chance we can get this priortised?
Comment 10 Eric Garver 2019-01-07 14:12:52 UTC 
(In reply to Peter Robinson from comment #9)
> Bump, any chance we can get this priortised?

There is also a request upstream, but at the moment it's not a priority.

https://github.com/firewalld/firewalld/issues/337
Note You need to log in before you can comment on or make changes to this bug.