Hello All,
What could be the reason for the following failure?
ugen2.2: at usbus2
umass0: on usbus2
umass0: RBC over CBI; quirks = 0x
umass0:1:0:-1: Attached to scbus1
(probe0:umass-sim0:0:0:0): AutoSense failed
This occurs on 4 different boxes, all on 8.1-RELEASE.
Never happened on previ
On Thu, Dec 09, 2010 at 10:35:56PM +0100, Harald Weis wrote:
> What could be the reason for the following failure?
>
> ugen2.2: at usbus2
> umass0: on usbus2
> umass0: RBC over CBI; quirks = 0x
> umass0:1:0:-1: Attached to scbus1
> (probe0:umass-sim0:0:0:0): AutoSense failed
>
> This occur
Is there a reason /sbin/reboot isn't assigned to the operator group or is
this an oversight?
--
Adam Vande More
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebs
In message , Adam
Vande More writes:
> Is there a reason /sbin/reboot isn't assigned to the operator group or is
> this an oversight?
Why would you want it to be? One really shouldn't be running /sbin/reboot
directly as part of normal operations. shutdown does a graceful reboot if
and when op
On Thu, Dec 9, 2010 at 11:10 PM, Mark Andrews wrote:
> Why would you want it to be? One really shouldn't be running /sbin/reboot
> directly as part of normal operations. shutdown does a graceful reboot if
> and when operators need to perform reboot.
>
AFAIK, the only functional difference be
> Date: Thu, 9 Dec 2010 23:35:51 -0600
> From: Adam Vande More
> Sender: owner-freebsd-sta...@freebsd.org
>
> On Thu, Dec 9, 2010 at 11:10 PM, Mark Andrews wrote:
>
> > Why would you want it to be? One really shouldn't be running /sbin/reboot
> > directly as part of normal operations. shutdo
On Thu, Dec 9, 2010 at 21:35, Adam Vande More wrote:
> On Thu, Dec 9, 2010 at 11:10 PM, Mark Andrews wrote:
>
>> Why would you want it to be? One really shouldn't be running /sbin/reboot
>> directly as part of normal operations. shutdown does a graceful reboot if
>> and when operators need to
On Fri, Dec 10, 2010 at 12:03 AM, Kevin Oberman wrote:
> Unlike reboot, shutdown attempts to cleanly stop all processes. Things
> like databases can be badly damaged by a reboot. Other processes save
> state when stopped and that is lost with a reboot.
>
For the correct order, "shutdown -r" call
In message , Adam
Vande More writes:
> On Fri, Dec 10, 2010 at 12:03 AM, Kevin Oberman wrote:
>
> > Unlike reboot, shutdown attempts to cleanly stop all processes. Things
> > like databases can be badly damaged by a reboot. Other processes save
> > state when stopped and that is lost with a reb
On Thu, Dec 9, 2010 at 22:46, Adam Vande More wrote:
> shutdown also give operator more possibilities than a clean shutdown some
> which could be very bad.
>
I haven't thought about the situation in any detail, but nothing jumps
out at me from the manpage. You could do a denial of service thing b
On Fri, Dec 10, 2010 at 1:04 AM, Mark Andrews wrote:
> When you have administered multi-user systems you learn to do things
> gracefully unless you actually need to do things abbruptly.
>
Yes I of course I use shutdown -r on a multi-user system in the rare times I
deal with one. However that's
In article ,
amvandem...@gmail.com writes:
>For the correct order, "shutdown -r" calls reboot which calls init which
>calls rc.shutdown.
No. shutdown(8) sends a SIGINT to init(8), which runs rc.shutdown and
then calls reboot(2) as its last act.
reboot(8) freezes init(8), then sends a SIGTERM t
12 matches
Mail list logo
