Re: Slow shutdown

On Thu, Jun 11, 2015 at 1:50 AM, Ranjan1018 . <214748mv_at_gmail.com> wrote:

> 2015-05-24 22:33 GMT+02:00 Garrett Cooper <yaneurabeya_at_gmail.com>:
>
> > On May 24, 2015, at 6:33, Ranjan1018 . <214748mv_at_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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_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: rkoberman_at_gmail.com