Date: Sun, 22 Feb 2009 19:43:39 -0800 From: Carl <k0802647@telus.net> To: Kevin Day <toasty@dragondata.com> Cc: freebsd-fs@freebsd.org Subject: Re: UFS2 and/or sparse file bug causing copy process to land in 'D'' state? Message-ID: <49A21B6B.7060709@telus.net> In-Reply-To: <CB040010-5DF9-4E73-9A15-63F01523D2F2@dragondata.com> References: <49A10626.8060705@telus.net> <20090222110052.GH41617@deviant.kiev.zoral.com.ua> <49A1E5CE.5000501@telus.net> <CB040010-5DF9-4E73-9A15-63F01523D2F2@dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kevin Day wrote: > On Feb 22, 2009, at 5:54 PM, Carl wrote: >> Is there some other way to forcibly reboot a remote system from the >> command line when a normal shutdown command is going to totally hang >> the system in this way? Or perhaps some kind of watchdog that has a >> good chance of surviving long enough to unjam a situation like this? > > reboot(8)'s man page: > > -n The file system cache is not flushed. This option should > probably not be used. > > -q The system is halted or restarted quickly and ungracefully, > and only the flushing of the file system cache is > performed (if the -n option is not specified). This > option should probably not be used. > > One or both of those would probably do it. Obviously I need to work on RTFM. I didn't look past shutdown(8). In my defence... I've got nothing. Thanks Kevin :-) A watchdog would still be valuable for those situations when one attempts a normal remote reboot, the system hangs, and sshd dies with it. Carl / K0802647
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49A21B6B.7060709>