Bug 1575764 - takes ages to stop firewalld on f28/macbookpro15
Summary: takes ages to stop firewalld on f28/macbookpro15
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Eric Garver
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-05-07 20:23 UTC by Lubos Kocman
Modified: 2019-05-28 18:54 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-28 18:54:46 UTC
Type: Bug


Attachments (Terms of Use)

Description Lubos Kocman 2018-05-07 20:23:49 UTC
Description of problem:

Hello this seem to be long lasting problem on mbp15. Basically every restart shutdown is waiting first about minute and half and then 3+ minutes to kill firewalld.

Same can be reproduced by simply running systemctl stop firewalld


Version-Release number of selected component (if applicable):

freshly installed f28

How reproducible:


Steps to Reproduce:
1. [lkocman@localhost bcwc_pcie]$ sudo systemctl stop firewalld
2. [lkocman@localhost bcwc_pcie]$ date
Mon May  7 22:21:35 CEST 2018


3.

Actual results:

systemctl stop firewalld doesn't exit in less than 3 minutes

[lkocman@localhost bcwc_pcie]$ sudo systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: failed (Result: timeout) since Mon 2018-05-07 22:19:11 CEST; 2min 27s ago
     Docs: man:firewalld(1)
  Process: 935 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=killed, signal=KILL)
 Main PID: 935 (code=killed, signal=KILL)
    Tasks: 1 (limit: 4915)
   Memory: 18.4M
   CGroup: /system.slice/firewalld.service
           └─4143 /sbin/rmmod nf_conntrack

May 07 22:16:10 localhost.localdomain systemd[1]: Stopping firewalld - dynamic firewall daemon...
May 07 22:17:41 localhost.localdomain systemd[1]: firewalld.service: State 'stop-sigterm' timed out. Killing.
May 07 22:17:41 localhost.localdomain systemd[1]: firewalld.service: Killing process 935 (firewalld) with signal SIGKILL.
May 07 22:17:41 localhost.localdomain systemd[1]: firewalld.service: Killing process 4143 (rmmod) with signal SIGKILL.
May 07 22:17:41 localhost.localdomain systemd[1]: firewalld.service: Killing process 1367 (gmain) with signal SIGKILL.
May 07 22:17:41 localhost.localdomain systemd[1]: firewalld.service: Main process exited, code=killed, status=9/KILL
May 07 22:17:41 localhost.localdomain systemd[1]: firewalld.service: Killing process 4143 (rmmod) with signal SIGKILL.
May 07 22:19:11 localhost.localdomain systemd[1]: firewalld.service: Processes still around after final SIGKILL. Entering failed mode.
May 07 22:19:11 localhost.localdomain systemd[1]: firewalld.service: Failed with result 'timeout'.
May 07 22:19:11 localhost.localdomain systemd[1]: Stopped firewalld - dynamic firewall daemon.
[lkocman@localhost bcwc_pcie]$ 

Expected results:


Additional info:

Comment 1 Lubos Kocman 2018-05-07 20:24:33 UTC
in case that this would be important

[lkocman@localhost bcwc_pcie]$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether f4:5c:89:9f:93:4b brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.157/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp4s0
       valid_lft 3105sec preferred_lft 3105sec
    inet6 fe80::7908:5335:37e:e353/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:79:8a:2d brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
4: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
    link/ether 52:54:00:79:8a:2d brd ff:ff:ff:ff:ff:ff
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1360 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 10.40.204.41/22 brd 10.40.207.255 scope global noprefixroute tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::1484:843d:11e:6086/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever
[lkocman@localhost bcwc_pcie]$

Comment 2 Ben Cotton 2019-05-02 21:49:52 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 3 Tibor Zimanyi 2019-05-28 12:31:48 UTC
I also have this same problem on Fedora 30 on Macbook Pro 15" 2015. It happens every shutdown.

Comment 4 Ben Cotton 2019-05-28 18:54:46 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.