Re: Small tip proposal for headless systems boot resiliency

[Mathieu Lubrano <mathieu%lubrano.at@localhost>]

Le 31 déc. 2013 à 00:59, Dave McGuire a écrit :

> On 12/30/2013 06:46 PM, Mathieu Lubrano wrote:
>> The headless systems, or boxes that may be far away are a pain to get
>> back online if stuck during the boot sequence... (embedded/headless
>> do not have IP-KVM or remote control).
>> 
>> 
>> * The point is : with a headless system you want it back online,
>> really. Even if it needs maintenance, you need a ssh or whatever to
>> get your hands dirty. So don't stop the boot sequence. If it's
>> damaged beyond basic/rescue usability, it makes no difference
>> anyway.
> 
>  This is, to put it simply, very dangerous.
> 
>  In fact it DOES make a difference, potentially a very large one.  If
> I've, say, put a NetBSD system in an industrial control environment
> (which is not an unlikely thing to do, and not even an unlikely thing
> for ME to do), and it's damaged so it's "partially" functional, I'd
> rather have it STOP COMPLETELY than, say, become confused and drive a
> gantry crane in the wrong direction.
> 
>  If something like this is done, it should be a configurable option.

Right, it makes sense to be safe in embedded systems and stop right away. Even 
for large servers (DB) you want to stop and fall back to a shell and manual 
fsck. 
But for many hosted systems, or headless systems you shouldn't stop the boot 
sequence for "minor" issues. Hands on operations may be avoided this way (think 
at colocation, VPS, old Servers and PCs revived with NetBSD...).

So like passing special arguments with fsck_flags, a "headless" flag or 
something like that in rc.conf, with a safe default setting (no change to the 
current behavior), seems fine to me.

I assumed it should be discussed from both "embedded" and "user" (like 
sysadmin) point of view, hence the cross-post...

> 
>                -Dave
> 
> -- 
> Dave McGuire, AK4HZ
> New Kensington, PA
>