Bug 876683

Summary:	RFE: make firewalld be a dbus activated service that exits after a period of inactivity
Product:	[Fedora] Fedora	Reporter:	Matthew Miller <mattdm>
Component:	firewalld	Assignee:	Eric Garver <egarver>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	jpopelka, pbrobinson, samuel-rhbugs, twoerner, walters, xzhou
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	245418, 1269538

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