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.
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.
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.
systemd stops wpa_supplicant.service before unmounting NFS.
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.
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.
Hmm, I'm probably wrong, as nfs mounts should be already considered as remote-fs...
Sorry to say you are wrong. Added that option to the fstab and there was no difference.
Hello, I have the same issue. Any quick workarounds available? I'm not yet familiar with systemd ... :-( Thanks.
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.
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)
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.
Could you please boot your machine with systemd.log_level=debug on the kernel command line and upload the output of "journalctl -b"?
Can you also put here output of: systemctl list-dependencies --after your_nfs_mount_unit_file.mount
I will do those in the morning as it is 22:20 where I live.
Created attachment 1042036 [details] systemctl list-dependencies --after syntegra.mount
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
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"
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.
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.
I modified /etc/systemd/wpa_supplicant.service to be have Before=remote-fs.target. No change. System still waiting long time on reboot.
Can you run systemctl list-jobs on the booted system?
[root@acer ~]# systemctl list-jobs No jobs running.
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.
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.
*** Bug 767818 has been marked as a duplicate of this bug. ***
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.)
(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.
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.
I can confirm that the workaround also works for me. Thank you Eric.
(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?
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. :-)
(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.
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.
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".)
*** Bug 1270369 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
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.
wpa_supplicant-2.4-6.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-6f16b5e39e
wpa_supplicant-2.4-6.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-1521e91178
wpa_supplicant-2.0-16.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-cfea96144a
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
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
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
"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!
(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
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.
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.
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.
wpa_supplicant-2.4-7.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-1521e91178
wpa_supplicant-2.0-17.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-cfea96144a
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
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
(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.
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.
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.
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 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.
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.
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.
Thank you Zbigniew, already submitted a new bug report.