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 1214466 - Interface is teared down if dbus-daemon exits. wpa_supplicant needs After=dbus.service in unit file.
Summary: Interface is teared down if dbus-daemon exits. wpa_supplicant needs After=dbu...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: wpa_supplicant
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 767818 1270369 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-04-22 18:44 UTC by Symeon Huang
Modified: 2016-07-27 00:37 UTC (History)
23 users (show)

Fixed In Version: wpa_supplicant-2.4-6.fc23 wpa_supplicant-2.0-17.fc21 wpa_supplicant-2.4-7.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-24 22:25:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
systemctl list-dependencies --after syntegra.mount (67.08 KB, image/jpeg)
2015-06-22 23:25 UTC, Ed Greshko
no flags Details
journal output (169.04 KB, application/x-gzip)
2015-06-23 00:17 UTC, Ed Greshko
no flags Details
journal output when shutting down (68.46 KB, text/plain)
2015-11-25 05:08 UTC, Tore Anderson
no flags Details

Description Symeon Huang 2015-04-22 18:44:48 UTC
Description of problem:
Suspected a race condition during shutdown. NFS points won't be able to be unmounted and cause a hang.

Version-Release number of selected component (if applicable): Fedora 22 Beta (keep up-to-date)

How reproducible:
Mount a NFS partition and shutdown.

Steps to Reproduce:
1. Mount a NFS
2. Shutdown

Actual results:
It'll hang. If ESC is pressed, it says "a stop job is running for /media/nfs"

Expected results:
No error, it should umount NFS points automatically and shutdown in a few seconds.

Additional info:
I noticed there is no such issue on F21 (just upgraded yesterday, it was normal back then). The NFS entry in my /etc/fstab is:

192.168.0.5:/media/Media    /media/nfs_media   nfs4    ro,noauto,user,x-systemd.automount,x-systemd.device-timeout=10,timeo=14 0 0

If I umount NFS point manually before shutdown, no hang would happen.

Comment 1 Clive Messer 2015-06-06 01:11:37 UTC
I'm seeing the same behavior. I think this is because the remote share is mounted over a wifi connection, and when shutting down systemd is taking down the wifi network connection before the nfs share is unmounted. Doesn't happen when (or at least I haven't seen it) when remote shares are mounted over an ethernet connection.

Comment 2 Ed Greshko 2015-06-12 07:05:34 UTC
I am also seeing this on a system where the network interface is WiFi with NFS4 mounts.  Doing this "/usr/bin/umount -a -t nfs4 ; /usr/bin/systemctl reboot" works.

Comment 3 Vsevolod Volkov 2015-06-13 14:04:09 UTC
systemd stops wpa_supplicant.service before unmounting NFS.

Comment 4 Tore Anderson 2015-06-14 14:45:14 UTC
Confirming. Fedora 22 with systemd-219-15.fc22.x86_64, NFS mounted over a NetworkManager-handled wifi connection securet with WPA2-PSK. During shutdown, the network is disconnected before the NFS mount is unmounted, causing the hang.

It will eventually time out and finish the shutdown, but it is a extremely long wait.

Comment 5 Jan Synacek 2015-06-18 13:15:06 UTC
Could you please try to add "_netdev" to the mount options?

I believe that when _netdev is not present, systemd actually treats the mount as a part of local-fs.target, not remote-fs.target.

Comment 6 Jan Synacek 2015-06-18 13:18:29 UTC
Hmm, I'm probably wrong, as nfs mounts should be already considered as remote-fs...

Comment 7 Ed Greshko 2015-06-19 02:12:45 UTC
Sorry to say you are wrong.  Added that option to the fstab and there was no difference.

Comment 8 axl 2015-06-21 19:18:06 UTC
Hello,
I have the same issue.
Any quick workarounds available?
I'm not yet familiar with systemd ... :-(
Thanks.

Comment 9 Ed Greshko 2015-06-21 23:05:31 UTC
The only quick workaround that I've found is to make an alias for rebooting and calling it instead of the normal way.  I do....

/usr/bin/umount -f -a -t nfs4 ; /usr/bin/systemctl reboot

I use KDE and sddm and tried to modify the sddm config files to do that same thing and ran into difficulties.

Comment 10 Jan Synacek 2015-06-22 12:41:05 UTC
I currently have no way how to test this, so I'm just guessing until then.

You can try the following:

1) # cp /usr/lib/systemd/system/wpa_supplicant.service /etc/systemd

2) open /etc/systemd/wpa_supplicant.service in your favorite text editor

3a) change Before=network.target to Before=network-online.target

3b) change Before=network.target to Before=NetworkManager-wait-online.service (do this only when you use NetworkManager)

Comment 11 Ed Greshko 2015-06-22 12:51:44 UTC
Since I do use NetworkManager I did steps 1, 2, and 3b.  I then issued a "/usr/bin/systemctl reboot" from the command line.  No change, still waiting forever.

Comment 12 Jan Synacek 2015-06-22 13:11:55 UTC
Could you please boot your machine with systemd.log_level=debug on the kernel command line and upload the output of "journalctl -b"?

Comment 13 Lukáš Nykrýn 2015-06-22 13:35:26 UTC
Can you also put here output of:
systemctl list-dependencies --after your_nfs_mount_unit_file.mount

Comment 14 Ed Greshko 2015-06-22 14:21:16 UTC
I will do those in the morning as it is 22:20 where I live.

Comment 15 Ed Greshko 2015-06-22 23:25:33 UTC
Created attachment 1042036 [details]
systemctl list-dependencies --after syntegra.mount

Comment 16 Ed Greshko 2015-06-22 23:26:57 UTC
I've attached a screenshot for this as well in the event the green/red indicators are meaningful.

[root@acer ~]# systemctl list-dependencies --after syntegra.mount
syntegra.mount
● ├─-.mount
● ├─system.slice
● ├─systemd-journald.socket
● ├─network-online.target
● │ ├─network.service
● │ ├─NetworkManager-wait-online.service
● │ └─network.target
● │   ├─firewalld.service
● │   ├─network.service
● │   ├─NetworkManager-wait-online.service
● │   ├─NetworkManager.service
● │   ├─wpa_supplicant.service
● │   └─network-pre.target
● ├─network.target
● │ ├─firewalld.service
● │ ├─network.service
● │ ├─NetworkManager-wait-online.service
● │ ├─NetworkManager.service
● │ ├─wpa_supplicant.service
● │ └─network-pre.target
● └─remote-fs-pre.target
●   ├─iscsi-shutdown.service
●   ├─iscsi.service
●   ├─iscsid.service
●   ├─iscsiuio.service
●   ├─nfs-server.service
●   └─nfs-client.target
●     ├─gssproxy.service
●     ├─rpc-gssd.service
●     └─rpc-svcgssd.service

Comment 17 Ed Greshko 2015-06-23 00:17:44 UTC
Created attachment 1042040 [details]
journal output

Here is the requested journalctl output.  I reverted to the initial system configuration, having deleted the /etc/systemd/wpa_supplicant.service change requested earlier.  I also did a full cycle.  Meaning I added the debug parameter to the kernel line, booted the system, did a normal reboot, waited for the reboot to complete and then booted the system to get the full journal using "journalctl -b -1"

Comment 18 Ed Greshko 2015-06-23 00:21:36 UTC
I forgot to mention one thing.  I believe the time change in the journal at 15:29:01 is due to the HW clock not being set to UTC.

Comment 19 Jan Synacek 2015-06-23 11:56:26 UTC
I attempted to extract relevant information from the logs.

The mounting sequence looks as it should:

Jun 23 07:29:29 acer.greshko.com systemd[1]: Started Preprocess NFS configuration.
Jun 23 07:29:29 acer.greshko.com systemd[1]: Mounted RPC Pipe File System.
Jun 23 07:29:35 acer.greshko.com systemd[1]: Started RPC security service for NFS server.
Jun 23 07:29:35 acer.greshko.com systemd[1]: Started RPC security service for NFS client and server.
Jun 23 07:29:35 acer.greshko.com systemd[1]: Reached target NFS client services.
Jun 23 07:29:36 acer.greshko.com systemd[1]: Started NTP client/server.
Jun 23 07:29:45 acer.greshko.com systemd[1]: Started Network Manager.
Jun 23 07:29:46 acer.greshko.com systemd[1]: Started WPA Supplicant daemon.
Jun 23 07:29:51 acer.greshko.com systemd[1]: Started Network Manager Wait Online.
Jun 23 07:29:51 acer.greshko.com systemd[1]: Reached target Network.
Jun 23 07:29:51 acer.greshko.com systemd[1]: Reached target Network is Online.
Jun 23 07:29:51 acer.greshko.com systemd[1]: Reached target Remote File Systems (Pre).
Jun 23 07:29:52 acer.greshko.com systemd[1]: Mounted /syntegra.

However, the shutdown (unmounting) sequence is a mess:

Jun 23 07:30:55 acer.greshko.com systemd[1]: Installed new job var-lib-nfs-rpc_pipefs.mount/stop as 1454
Jun 23 07:30:55 acer.greshko.com systemd[1]: Installed new job syntegra.mount/stop as 1460
Jun 23 07:30:55 acer.greshko.com systemd[1]: Installed new job nfs-client.target/stop as 1438
Jun 23 07:30:55 acer.greshko.com systemd[1]: About to execute: /bin/umount /var/lib/nfs/rpc_pipefs -n
Jun 23 07:30:55 acer.greshko.com systemd[1]: var-lib-nfs-rpc_pipefs.mount changed mounted -> unmounting
Jun 23 07:30:55 acer.greshko.com systemd[1686]: Executing: /bin/umount /var/lib/nfs/rpc_pipefs -n
Jun 23 07:30:55 acer.greshko.com systemd[1]: Stopped WPA Supplicant daemon.
Jun 23 07:30:56 acer.greshko.com systemd[1523]: Stopped target Default.
Jun 23 07:30:56 acer.greshko.com systemd[1523]: Stopped target Basic System.
Jun 23 07:30:56 acer.greshko.com systemd[1523]: Stopped target Paths.
Jun 23 07:30:56 acer.greshko.com systemd[1523]: Reached target Shutdown.
Jun 23 07:30:56 acer.greshko.com systemd[1546]: Stopped target Default.
Jun 23 07:30:56 acer.greshko.com systemd[1523]: Stopped target Sockets.
Jun 23 07:30:56 acer.greshko.com systemd[1546]: Stopped target Basic System.
Jun 23 07:30:56 acer.greshko.com systemd[1523]: Stopped target Timers.
Jun 23 07:30:56 acer.greshko.com systemd[1546]: Reached target Shutdown.
Jun 23 07:30:56 acer.greshko.com systemd[1546]: Stopped target Paths.
Jun 23 07:30:56 acer.greshko.com systemd[1546]: Stopped target Timers.
Jun 23 07:30:56 acer.greshko.com systemd[1546]: Stopped target Sockets.
Jun 23 07:30:56 acer.greshko.com systemd[1546]: var-lib-nfs-rpc_pipefs.mount changed mounted -> dead
Jun 23 07:30:56 acer.greshko.com systemd[1523]: var-lib-nfs-rpc_pipefs.mount changed mounted -> dead
Jun 23 07:30:56 acer.greshko.com systemd[1]: Job var-lib-nfs-rpc_pipefs.mount/stop finished, result=done
Jun 23 07:30:58 acer.greshko.com systemd[1]: Stopped target Remote File Systems.
Jun 23 07:30:58 acer.greshko.com systemd[1]: About to execute: /bin/umount /syntegra -n
Jun 23 07:30:58 acer.greshko.com systemd[1]: syntegra.mount changed mounted -> unmounting
Jun 23 07:30:58 acer.greshko.com systemd[1733]: Executing: /bin/umount /syntegra -n
Jun 23 07:30:58 acer.greshko.com systemd[1]: Unmounting /syntegra...
Jun 23 07:30:58 acer.greshko.com systemd[1]: Stopped target User and Group Name Lookups.
Jun 23 07:32:28 acer.greshko.com systemd[1]: syntegra.mount unmounting timed out. Stopping.
Jun 23 07:32:28 acer.greshko.com systemd[1]: syntegra.mount changed unmounting -> unmounting-sigterm
Jun 23 07:32:28 acer.greshko.com systemd[1]: Child 1733 belongs to syntegra.mount
Jun 23 07:32:28 acer.greshko.com systemd[1]: syntegra.mount mount process exited, code=killed status=15
Jun 23 07:32:28 acer.greshko.com systemd[1]: syntegra.mount: mount still present, trying again.
Jun 23 07:32:28 acer.greshko.com systemd[1]: About to execute: /bin/umount /syntegra -n
Jun 23 07:32:28 acer.greshko.com systemd[1]: syntegra.mount changed unmounting-sigterm -> unmounting
Jun 23 07:34:53 acer.greshko.com kernel: nfs: server ds not responding, timed out

There seems to be absolutely no adherence to shutting things down in correct order. WPA Supplicant goes first, even before Remote File Systems. There is also no sign of the network being shut down correctly, for example NetworkManager seems to be running until the end of the shutdown sequence (visible in the original log) and is then killed as a remaining process.

I'm not even sure how to work around this issue. Maybe trying to order wpa_supplicant.service Before=remote-fs.target would help.

Comment 20 Ed Greshko 2015-06-23 12:20:29 UTC
I modified /etc/systemd/wpa_supplicant.service to be have Before=remote-fs.target.  No change.  System still waiting long time on reboot.

Comment 21 Lukáš Nykrýn 2015-06-23 13:59:50 UTC
Can you run systemctl list-jobs on the booted system?

Comment 22 Ed Greshko 2015-06-23 14:12:43 UTC
[root@acer ~]# systemctl list-jobs
No jobs running.

Comment 23 Roderick Johnstone 2015-06-29 09:01:03 UTC
I'm not sure whether to chip in here or open a new BZ.

I'm essentially seeing the same behaviour of long pauses (waiting on systemd shutdown timeouts) on shutdown with NFS mounted filesystems on F22, but in my case its with a NetworkManager controlled wired connection.

Happy to run diagnostics, or open a new BZ if you'd rather keep this one focused on the wireless shutdown issues.

Comment 24 Ed Greshko 2015-06-29 09:07:46 UTC
FWIW, I am not seeing any problems in shutdown or reboot on my F22 system with a wired network, managed by NetworkManager and in my case using static addresses.

In your case, the first thing I would do is boot the system and remove rhgb and quiet from the kernel parameters once the system comes up, reboot or shutdown to confirm it is waiting on an unmount.

Comment 25 Jan Synacek 2015-06-29 11:02:34 UTC
*** Bug 767818 has been marked as a duplicate of this bug. ***

Comment 26 Clive Messer 2015-07-05 02:40:46 UTC
Has there been any progress on this problem?

I foolishly (with the benefit of hindsight) upgraded a classroom situation, comprising 20x Intel NUC desktops (with /home mounted over NFS via onboard wifi) from F21 to F22. I am getting my backside kicked over this now. (Re-imaging those machines with Ubuntu, is what I am now being asked to do, because of this issue.)

Comment 27 Ed Greshko 2015-07-05 03:52:14 UTC
(In reply to Clive Messer from comment #26)
> Has there been any progress on this problem?
> 
> I foolishly (with the benefit of hindsight) upgraded a classroom situation,
> comprising 20x Intel NUC desktops (with /home mounted over NFS via onboard
> wifi) from F21 to F22. I am getting my backside kicked over this now.
> (Re-imaging those machines with Ubuntu, is what I am now being asked to do,
> because of this issue.)

While I've not tested it please be aware that this problem may be related to systemd and Ubuntu, I believe, has switched to systemd.  So, there is no guarantee that moving to Ubuntu will correct the issue.

There is a simple workaround that I note in comment#9.  I have to use it manually since I've problems to get sddm to honor changes to the config file.  Don't know if gdm or other display managers would fare any better.

Comment 28 Eric Bakkum 2015-07-06 21:43:43 UTC
I ran into this problem as well. After some searching I found the same bug (I think) reported for Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1438612 

The workaround for me was to copy /usr/lib/systemd/system/dbus.service to /etc/systemd/system/dbus.service and update the latter by appending

	ExecStop=/bin/sh -c "echo Stopping dbus-daemon is disabled.; exit 1"
	KillMode=none

to the end of the [Service] section.

Comment 29 Ed Greshko 2015-07-06 23:58:08 UTC
I can confirm that the workaround also works for me.  Thank you Eric.

Comment 30 Eric Bakkum 2015-07-07 08:43:08 UTC
(In reply to Eric Bakkum from comment #28)

The workaround that I derived from the Ubuntu bug report was discussed by upstream freedesktop.org D-Bus in
	https://bugs.freedesktop.org/show_bug.cgi?id=89847
where it apparently is not considered to be a sufficiently solid solution, and the bug is closed with "don't fix". They seem to suggest fixes in wpasupplicant.service and NetworkManager.service .

The Ubuntu bug report shows an earlier Ubuntu dbus patch release in line with the workaround.

I am not that familiar with the fedora bug fixing process. The workaround is fine for me, but in the long run a real fix is preferable. What is supposed to happen next?

Comment 31 Ed Greshko 2015-07-07 09:07:17 UTC
Thanks for continuing researching....

I have removed the workaround shown in #28 and have made suggested changes to both    wpasupplicant.service and NetworkManager.service and confirmed that it also fixes the problem.

I also don't know what is supposed to happen next.  :-)

Comment 32 Eric Bakkum 2015-07-07 10:18:43 UTC
(In reply to Ed Greshko from comment #31)

Thanks for that test. Adding the After=dbus.service to the two service files in stead of the workaround works for me as well.

And no more "Unit dbus.service entered failed state" in journalctl anymore, so this seems to be an improvement.

Comment 33 Clive Messer 2015-07-07 15:15:02 UTC
Yes, having modded the wpa_supplicant and NetworkManager service configs on my laptop, by adding "After=dbus.service".... that seems to be the most sensible work-around for the moment until someone who is an expert with systemd dependencies says otherwise.

Comment 34 Tore Anderson 2015-08-21 08:17:54 UTC
This bug is also present in Fedora 23 (wpa_supplicant-2.4-4.fc23.x86_64). It's a shame, really, since this is a quite annoying bug with what appears to be a really simple fix.

For what it's worth, when implementing the workaround, rather than editing the wpa_supplicant.service directly it's probably better to make use of systemd's drop-in functionality to add the dbus dependency on top of the original file, like so:

1) mkdir /etc/systemd/system/wpa_supplicant.service.d
2) echo $'[Unit]\nAfter=dbus.service' > /etc/systemd/system/wpa_supplicant.service.d/override.conf
3) systemctl daemon-reload

(Steps #1 and #2 can be replaced with "systemctl edit wpa_supplicant.service".)

Comment 35 Jan Synacek 2015-10-12 07:36:44 UTC
*** Bug 1270369 has been marked as a duplicate of this bug. ***

Comment 36 Fedora Admin XMLRPC Client 2015-10-14 14:50:14 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 37 Clive Messer 2015-11-02 19:08:09 UTC
This is still a problem in F23. Please can the maintainer of the wpa_supplicant package update the service file! Clue: "After=dbus.service". Thank you.

Comment 38 Fedora Update System 2015-11-03 11:28:29 UTC
wpa_supplicant-2.4-6.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-6f16b5e39e

Comment 39 Fedora Update System 2015-11-03 11:31:06 UTC
wpa_supplicant-2.4-6.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-1521e91178

Comment 40 Fedora Update System 2015-11-03 11:32:00 UTC
wpa_supplicant-2.0-16.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-cfea96144a

Comment 41 Fedora Update System 2015-11-03 18:21:27 UTC
wpa_supplicant-2.0-16.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update wpa_supplicant'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-cfea96144a

Comment 42 Fedora Update System 2015-11-03 18:56:51 UTC
wpa_supplicant-2.4-6.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update wpa_supplicant'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-1521e91178

Comment 43 Fedora Update System 2015-11-03 19:52:58 UTC
wpa_supplicant-2.4-6.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update wpa_supplicant'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-6f16b5e39e

Comment 44 Clive Messer 2015-11-04 00:11:25 UTC
"After=dbus.service" in the service file, results in the supplicant not being stopped before the network shares are unmounted. "Wants=network.target", does not!

Comment 45 Eric Bakkum 2015-11-04 12:01:33 UTC
(In reply to Fedora Update System from comment #42)

With this fix the problem still exists as before. In my case "After=dbus.service" is really required to solve the issue.

So this is the /usr/lib/systemd/system/wpa_supplicant.service that works for me:

[Unit]
Description=WPA Supplicant daemon
Before=network.target
After=syslog.target dbus.service

[Service]
Type=dbus
BusName=fi.w1.wpa_supplicant1
EnvironmentFile=-/etc/sysconfig/wpa_supplicant
ExecStart=/usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf $INTERFACES $DRIVERS $OTHER_ARGS

[Install]
WantedBy=multi-user.target

Comment 46 Fedora Update System 2015-11-12 23:28:14 UTC
wpa_supplicant-2.4-6.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 47 Clive Messer 2015-11-13 02:43:30 UTC
This bug is now closed! But it is not fixed!

I -1'd the update in bodhi, specifically -1'd this fix for this bugzilla id because the update didn't fix the issue. Not sure what more I could have done.

Comment 48 Adam Williamson 2015-11-13 02:53:06 UTC
Nothing, really - apparently Bodhi hasn't been set to disable the 'close bugs when update pushed stable' behaviour for that kind of feedback. We can just re-open the bug, but it'll get closed again when the F22 and F21 updates are pushed stable.

Comment 49 Fedora Update System 2015-11-16 17:48:28 UTC
wpa_supplicant-2.4-7.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-1521e91178

Comment 50 Fedora Update System 2015-11-16 17:51:51 UTC
wpa_supplicant-2.0-17.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-cfea96144a

Comment 51 Fedora Update System 2015-11-19 00:23:11 UTC
wpa_supplicant-2.4-7.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update wpa_supplicant'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-1521e91178

Comment 52 Fedora Update System 2015-11-21 00:51:08 UTC
wpa_supplicant-2.0-17.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update wpa_supplicant'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-cfea96144a

Comment 53 Tore Anderson 2015-11-21 14:31:56 UTC
(In reply to Fedora Update System from comment #46)
> wpa_supplicant-2.4-6.fc23 has been pushed to the Fedora 23 stable
> repository. If problems still persist, please make note of it in this bug
> report.

Yes, problems do still persist in wpa_supplicant-2.4-6.fc23.x86_64. The network is disconnected before the remote filesystem is unmounted. Relevant log entries from the journal is attached:

nov. 21 15:17:29 envy.fud.no systemd-logind[839]: System is rebooting.
[...]
nov. 21 15:17:29 envy.fud.no systemd[1]: Stopping D-Bus System Message Bus...
[...]
nov. 21 15:17:29 envy.fud.no NetworkManager[984]: <info>  caught SIGTERM, shutting down normally.
[...]
nov. 21 15:17:29 envy.fud.no NetworkManager[984]: <info>  exiting (success)
nov. 21 15:17:29 envy.fud.no systemd[1]: Stopped Network Manager.
nov. 21 15:17:34 envy.fud.no systemd[1]: Stopped target Remote File Systems.
nov. 21 15:17:34 envy.fud.no systemd[1]: Stopping Remote File Systems.
nov. 21 15:17:34 envy.fud.no systemd[1]: Unmounting /fud...
nov. 21 15:17:34 envy.fud.no systemd[1]: Stopped Login Service.
[...]
nov. 21 15:19:04 envy.fud.no systemd[1]: fud.mount: Unmounting timed out. Stopping.
nov. 21 15:19:25 envy.fud.no kernel: CIFS VFS: Server lust.e1.x.home has not responded in 120 seconds. Reconnecting...
nov. 21 15:19:45 envy.fud.no systemd[1]: Unmounted /fud.
nov. 21 15:19:45 envy.fud.no systemd[1]: fud.mount: Unit entered failed state.
nov. 21 15:19:45 envy.fud.no systemd[1]: Stopped target Network is Online.
nov. 21 15:19:45 envy.fud.no systemd[1]: Stopping Network is Online.
nov. 21 15:19:45 envy.fud.no systemd[1]: Unset automount fud.automount.
nov. 21 15:19:45 envy.fud.no systemd[1]: Stopping fud.automount.
nov. 21 15:19:45 envy.fud.no systemd[1]: Stopped target Remote File Systems (Pre).
nov. 21 15:19:45 envy.fud.no systemd[1]: Stopping Remote File Systems (Pre).
[...]

As you can see, the issue caused the shutdown process to stall for 2 minutes and 9 seconds.

Comment 54 Fedora Update System 2015-11-23 23:20:27 UTC
wpa_supplicant-2.0-17.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.

Comment 55 Fedora Update System 2015-11-24 22:24:51 UTC
wpa_supplicant-2.4-7.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Comment 56 Tore Anderson 2015-11-25 05:08:57 UTC
Created attachment 1098536 [details]
journal output when shutting down

wpa_supplicant-2.4-7.fc22.x86_64 still gives me hangs during shutdown due to the network being disconnected before the remote file system is unmounted.

I'm attaching a full journal output from a shutdown procedure. The unmount timeout happens at 23:53:54.

From the output it seems that wpa_supplicant is indeed stopped after the unmount is attempted (at 23:54:46), so it might very well be that there has been some other change in F23 that is also causing the same issue that "After=dbus.service" used successfully work around in F22.

Comment 57 Tore Anderson 2015-11-25 05:19:30 UTC
Comment on attachment 1098536 [details]
journal output when shutting down

Please disregard comment #56. The problem there was that the network connection profile used had "permissions=user:tore:;" set (apparently the default). That caused NetworkManager to start tearing down the network as soon as my user logged out.

After changing to "permissions=", this no longer happens. That is, wpa_supplicant-2.4-7.fc22.x86_64 successfully resolves the unmount hang during shutdown for me.

Comment 58 Gerardo Rosales 2016-07-23 18:18:59 UTC
Hi guys, I'm not sure if it is OK to post this here but I'm having this issue with Fedora 24 KDE,


The log file shows the following:
----------------------------------------------------------------------------
Jul 23 10:16:36 x201 systemd[1]: mnt-amdpc-Learning.mount: Unmounting timed out. Stopping.
Jul 23 10:16:36 x201 systemd[1]: mnt-amdpc-Music.mount: Unmounting timed out. Stopping.
Jul 23 10:16:36 x201 systemd[1]: mnt-amdpc-Clientes.mount: Unmounting timed out. Stopping.
Jul 23 10:16:36 x201 systemd[1]: mnt-amdpc-Pictures.mount: Unmounting timed out. Stopping.
Jul 23 10:18:06 x201 kernel: nfs: server 192.168.0.50 not responding, timed out
Jul 23 10:18:06 x201 kernel: nfs: server 192.168.0.50 not responding, timed out
Jul 23 10:18:06 x201 systemd[1]: mnt-amdpc-Learning.mount: Unmounting timed out. Stopping.
Jul 23 10:18:06 x201 systemd[1]: mnt-amdpc-Pictures.mount: Unmounting timed out. Stopping.
Jul 23 10:18:06 x201 systemd[1]: mnt-amdpc-Clientes.mount: Unmounting timed out. Stopping.
Jul 23 10:18:06 x201 systemd[1]: mnt-amdpc-Music.mount: Unmounting timed out. Stopping.
Jul 23 10:19:36 x201 systemd[1]: mnt-amdpc-Learning.mount: Unmounting timed out. Stopping.
Jul 23 10:19:36 x201 systemd[1]: mnt-amdpc-Music.mount: Unmounting timed out. Stopping.
Jul 23 10:19:36 x201 systemd[1]: mnt-amdpc-Clientes.mount: Unmounting timed out. Stopping.
Jul 23 10:19:36 x201 systemd[1]: mnt-amdpc-Pictures.mount: Unmounting timed out. Stopping.
Jul 23 10:20:22 x201 NetworkManager[952]: <info>  [1469290822.3455] connectivity: check for uri 'http://fedoraproject.org/static/hotspot.txt' failed with 'Error resolving 'fedoraproject.org': Name or service not known'
Jul 23 10:21:06 x201 kernel: nfs: server 192.168.0.50 not responding, timed out
Jul 23 10:21:06 x201 kernel: nfs: server 192.168.0.50 not responding, timed out
Jul 23 10:21:07 x201 systemd[1]: mnt-amdpc-Learning.mount: Unmounting timed out. Stopping.
Jul 23 10:21:07 x201 systemd[1]: mnt-amdpc-Clientes.mount: Unmounting timed out. Stopping.
Jul 23 10:21:07 x201 systemd[1]: mnt-amdpc-Music.mount: Unmounting timed out. Stopping.
Jul 23 10:21:07 x201 systemd[1]: mnt-amdpc-Pictures.mount: Unmounting timed out. Stopping.
Jul 23 10:22:37 x201 systemd[1]: mnt-amdpc-Learning.mount: Unmounting timed out. Stopping.
Jul 23 10:22:37 x201 systemd[1]: mnt-amdpc-Music.mount: Unmounting timed out. Stopping.
Jul 23 10:22:37 x201 systemd[1]: mnt-amdpc-Pictures.mount: Unmounting timed out. Stopping.
Jul 23 10:22:37 x201 systemd[1]: mnt-amdpc-Clientes.mount: Unmounting timed out. Stopping.
Jul 23 10:24:06 x201 kernel: nfs: server 192.168.0.50 not responding, timed out
Jul 23 10:24:06 x201 kernel: nfs: server 192.168.0.50 not responding, timed out
Jul 23 10:24:07 x201 systemd[1]: mnt-amdpc-Learning.mount: Unmounting timed out. Stopping.
Jul 23 10:24:07 x201 systemd[1]: mnt-amdpc-Pictures.mount: Unmounting timed out. Stopping.
Jul 23 10:24:07 x201 systemd[1]: mnt-amdpc-Clientes.mount: Unmounting timed out. Stopping.
Jul 23 10:24:07 x201 systemd[1]: mnt-amdpc-Music.mount: Unmounting timed out. Stopping.
Jul 23 10:25:22 x201 NetworkManager[952]: <info>  [1469291122.3525] connectivity: check for uri 'http://fedoraproject.org/static/hotspot.txt' failed with 'Error resolving 'fedoraproject.org': Name or service not known'
Jul 23 10:25:33 x201 systemd[1]: poweroff.target: Job poweroff.target/start timed out.
Jul 23 10:25:33 x201 systemd[1]: Timed out starting Power-Off.
Jul 23 10:25:33 x201 systemd[1]: poweroff.target: Job poweroff.target/start failed with result 'timeout'.
Jul 23 10:25:33 x201 systemd[1]: Forcibly powering off as result of failure.
Jul 23 10:25:33 x201 systemd[1]: Shutting down.
Jul 23 10:25:33 x201 systemd-shutdown[1]: Sending SIGTERM to remaining processes...
Jul 23 10:25:33 x201 systemd-journald[572]: Journal stopped
-----------------------------------------------------------------------------

dnf info  wpa_supplicant shows the following:
Installed Packages
Name        : wpa_supplicant
Arch        : x86_64
Epoch       : 1
Version     : 2.5
Release     : 5.fc24
Size        : 3.9 M
Repo        : @System
From repo   : koji-override-0
Summary     : WPA/WPA2/IEEE 802.1X Supplicant
URL         : http://w1.fi/wpa_supplicant/
License     : BSD

Let me know if I need to open a new ticket and thank you in advance.

Comment 59 Zbigniew Jędrzejewski-Szmek 2016-07-23 18:42:31 UTC
I think you're better of opening another bug report, with a See also for this one.
And I think you need to include full shutdown logs — in the part that you pasted the NFS server is already non-responsive, so the real problem happened before.

Comment 60 Gerardo Rosales 2016-07-27 00:37:52 UTC
Thank you Zbigniew, already submitted a new bug report.


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