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.”
> > > 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:
> With this patch shutting down my laptop appear as:
> For testing the the patch apply it in /sys/kern, rebuild and install the
> Set the new OID:
> # sysctl kern.shutdown.show_umountfs=1
> Halt the system:
> # shutdown -h now
> email@example.com mailing list
> 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
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"