Re: Slow shutdown
On Fri, Jun 12, 2015 at 1:30 AM, Ranjan1018 . 21474...@gmail.com wrote: 2015-06-12 1:13 GMT+02:00 Henry Hu henry.hu...@gmail.com: On Thu, Jun 11, 2015 at 1:55 PM Kevin Oberman rkober...@gmail.com wrote: The same issue exists in fusefs, but has an uglier result. The fuse daemon shuts down before any fusefs based file systems are unmounted, but, for several R/W file systems including NTFS and exFAT, the result is a corrupt file system. I did the same thing to work around this problem... an init script, but I wonder if this should not be handled in some cleaner and more global manner. (No, I have no idea right now of how to implement this.) I think that I've hit this problem several times, because I've lost files on my NTFS portable harddisk several times. Now I force an unmount in the shutdown script. I remember that when fuse module was still in fusefs-kmod, the rc script unmounts the file systems, and there's even a _safe flag to ensure safety. Hi, I have the same issue in my laptop a dual boot FreeBSD/Windows 8. In FreeBSD, the Win8 partition, is mounted via fusefs and is unmounted in a shutdown script. But if I do not unmount this partition in a script, it is not unmounted by the OS or fusefs at shutdown. Probably this is a different or new bug. For the original bug I have opened a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200784 Please comment here if you like. Regards, Maurizio I also opened a bug report for the fusefs case. It is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200513. It includes a shutdown script that will unmount the file systems cleanly, though it will unmount all fusefs file systems, whether they need it or not. Many fusefs file systems are read-only or fully synchronous, so are always clean. But, as far as I can tell, unmounting does not harm for any fusefs file system. (Yes, fusefs file system is probably redundant.) The shutdown script is only for systems running the native fusefs code and not the older fusefs-kmod port. -- Kevin Oberman, Network Engineer, Retired ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow shutdown
2015-06-12 1:13 GMT+02:00 Henry Hu henry.hu...@gmail.com: On Thu, Jun 11, 2015 at 1:55 PM Kevin Oberman rkober...@gmail.com wrote: The same issue exists in fusefs, but has an uglier result. The fuse daemon shuts down before any fusefs based file systems are unmounted, but, for several R/W file systems including NTFS and exFAT, the result is a corrupt file system. I did the same thing to work around this problem... an init script, but I wonder if this should not be handled in some cleaner and more global manner. (No, I have no idea right now of how to implement this.) I think that I've hit this problem several times, because I've lost files on my NTFS portable harddisk several times. Now I force an unmount in the shutdown script. I remember that when fuse module was still in fusefs-kmod, the rc script unmounts the file systems, and there's even a _safe flag to ensure safety. Hi, I have the same issue in my laptop a dual boot FreeBSD/Windows 8. In FreeBSD, the Win8 partition, is mounted via fusefs and is unmounted in a shutdown script. But if I do not unmount this partition in a script, it is not unmounted by the OS or fusefs at shutdown. Probably this is a different or new bug. For the original bug I have opened a PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200784 Please comment here if you like. Regards, Maurizio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow shutdown
2015-05-24 22:33 GMT+02:00 Garrett Cooper yaneurab...@gmail.com: On May 24, 2015, at 6:33, Ranjan1018 . 21474...@gmail.com wrote: On my laptop running r283297, after the message “All buffers synced.” and before “Uptime: …..” it takes more than 55 seconds. Not a lot of info here to diagnose your issue... - What happens if you hit control-t, i.e. what wait channel does it print out? - What filesystems do you have mounted (fuse, NFS, UFS, ZFS)? - What’s your root media (SSDs, SATA/PATA hard drives, etc)? Thanks.. Solved ! The slow shutdown is caused by some remote smbfs shares mounted via openvpn: the remote drives are unmounted after the openvpn daemon termination, this induces some long timeout. The solution is to unmount the smbfs shares in a shutdown script before the openvpn daemon termination. I have discovered this issue with this ‘dirty’ patch that displays the unmounted fs at shutdown: http://pastebin.com/Xfiz9nsv With this patch shutting down my laptop appear as: https://drive.google.com/file/d/0BzoWQoMqq1sfcHZyRnlEeTRobFU/view?usp=sharing . For testing the the patch apply it in /sys/kern, rebuild and install the kernel. Set the new OID: # sysctl kern.shutdown.show_umountfs=1 Halt the system: # shutdown -h now Regards, Maurizio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow shutdown
On Thu, Jun 11, 2015 at 1:50 AM, Ranjan1018 . 21474...@gmail.com wrote: 2015-05-24 22:33 GMT+02:00 Garrett Cooper yaneurab...@gmail.com: On May 24, 2015, at 6:33, Ranjan1018 . 21474...@gmail.com wrote: On my laptop running r283297, after the message “All buffers synced.” and before “Uptime: …..” it takes more than 55 seconds. Not a lot of info here to diagnose your issue... - What happens if you hit control-t, i.e. what wait channel does it print out? - What filesystems do you have mounted (fuse, NFS, UFS, ZFS)? - What’s your root media (SSDs, SATA/PATA hard drives, etc)? Thanks.. Solved ! The slow shutdown is caused by some remote smbfs shares mounted via openvpn: the remote drives are unmounted after the openvpn daemon termination, this induces some long timeout. The solution is to unmount the smbfs shares in a shutdown script before the openvpn daemon termination. I have discovered this issue with this ‘dirty’ patch that displays the unmounted fs at shutdown: http://pastebin.com/Xfiz9nsv With this patch shutting down my laptop appear as: https://drive.google.com/file/d/0BzoWQoMqq1sfcHZyRnlEeTRobFU/view?usp=sharing . For testing the the patch apply it in /sys/kern, rebuild and install the kernel. Set the new OID: # sysctl kern.shutdown.show_umountfs=1 Halt the system: # shutdown -h now Regards, Maurizio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org The same issue exists in fusefs, but has an uglier result. The fuse daemon shuts down before any fusefs based file systems are unmounted, but, for several R/W file systems including NTFS and exFAT, the result is a corrupt file system. I did the same thing to work around this problem... an init script, but I wonder if this should not be handled in some cleaner and more global manner. (No, I have no idea right now of how to implement this.) -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow shutdown
On Thu, Jun 11, 2015 at 1:55 PM Kevin Oberman rkober...@gmail.com wrote: On Thu, Jun 11, 2015 at 1:50 AM, Ranjan1018 . 21474...@gmail.com wrote: 2015-05-24 22:33 GMT+02:00 Garrett Cooper yaneurab...@gmail.com: On May 24, 2015, at 6:33, Ranjan1018 . 21474...@gmail.com wrote: On my laptop running r283297, after the message “All buffers synced.” and before “Uptime: …..” it takes more than 55 seconds. Not a lot of info here to diagnose your issue... - What happens if you hit control-t, i.e. what wait channel does it print out? - What filesystems do you have mounted (fuse, NFS, UFS, ZFS)? - What’s your root media (SSDs, SATA/PATA hard drives, etc)? Thanks.. Solved ! The slow shutdown is caused by some remote smbfs shares mounted via openvpn: the remote drives are unmounted after the openvpn daemon termination, this induces some long timeout. The solution is to unmount the smbfs shares in a shutdown script before the openvpn daemon termination. I have discovered this issue with this ‘dirty’ patch that displays the unmounted fs at shutdown: http://pastebin.com/Xfiz9nsv With this patch shutting down my laptop appear as: https://drive.google.com/file/d/0BzoWQoMqq1sfcHZyRnlEeTRobFU/view?usp=sharing . For testing the the patch apply it in /sys/kern, rebuild and install the kernel. Set the new OID: # sysctl kern.shutdown.show_umountfs=1 Halt the system: # shutdown -h now Regards, Maurizio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org The same issue exists in fusefs, but has an uglier result. The fuse daemon shuts down before any fusefs based file systems are unmounted, but, for several R/W file systems including NTFS and exFAT, the result is a corrupt file system. I did the same thing to work around this problem... an init script, but I wonder if this should not be handled in some cleaner and more global manner. (No, I have no idea right now of how to implement this.) I think that I've hit this problem several times, because I've lost files on my NTFS portable harddisk several times. Now I force an unmount in the shutdown script. I remember that when fuse module was still in fusefs-kmod, the rc script unmounts the file systems, and there's even a _safe flag to ensure safety. -- Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow shutdown
2015-05-24 22:33 GMT+02:00 Garrett Cooper yaneurab...@gmail.com: On May 24, 2015, at 6:33, Ranjan1018 . 21474...@gmail.com wrote: On my laptop running r283297, after the message “All buffers synced.” and before “Uptime: …..” it takes more than 55 seconds. Not a lot of info here to diagnose your issue... - What happens if you hit control-t, i.e. what wait channel does it print out? control-t doesn't works. - What filesystems do you have mounted (fuse, NFS, UFS, ZFS)? ZFS and NTFS via fuse, removing NTFS mount doesn't reduce the shutdown time. - What’s your root media (SSDs, SATA/PATA hard drives, etc)? SATA. Thanks.. Thanks to you. I noticed that with the command ‘shutdown -h now’ the phrase “The operating system has halted. Please press any key to reboot.” is missing, pressing a key the laptop reboots. Maurizio ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Slow shutdown
On May 24, 2015, at 6:33, Ranjan1018 . 21474...@gmail.com wrote: On my laptop running r283297, after the message “All buffers synced.” and before “Uptime: …..” it takes more than 55 seconds. Not a lot of info here to diagnose your issue... - What happens if you hit control-t, i.e. what wait channel does it print out? - What filesystems do you have mounted (fuse, NFS, UFS, ZFS)? - What’s your root media (SSDs, SATA/PATA hard drives, etc)? Thanks.. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Slow shutdown
On Sun, May 24, 2015 at 1:33 PM, Garrett Cooper yaneurab...@gmail.com wrote: On May 24, 2015, at 6:33, Ranjan1018 . 21474...@gmail.com wrote: On my laptop running r283297, after the message “All buffers synced.” and before “Uptime: …..” it takes more than 55 seconds. Not a lot of info here to diagnose your issue... - What happens if you hit control-t, i.e. what wait channel does it print out? - What filesystems do you have mounted (fuse, NFS, UFS, ZFS)? - What’s your root media (SSDs, SATA/PATA hard drives, etc)? Thanks.. By this point in the shutdown, ctrl-t (and the shell, itself) are no longer available. This feels like it might be related to the very messy issue with shutdown that triggered the EN and patched 10.1 release. That one was the result of a composite of several bugs and is believed fixed, but,in most cases, shutting down to single user and waiting for 1 minute (pretty close to 55 seconds) before issuing a halt fixed the problem. One difference... a shutdown -r or shutdown -p never completed. It just hung. At least an odd coincidence. This issue only occurred on SU+J UFS file systems. Since this is default for UFS systems, it's pretty likely that any UFS file systems are SU+J. You can try turning this off (tunefs(9)) and see if it helps. If you crash without this, the fsck will take a while, though, if it is a large FS. It was patched in 10.1 with r282873. I have only heard of this bug impacting 10.1, not head, but the similarity makes me suspect some link. -- Kevin Oberman, Network Engineer, Retired ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
