[RADIATOR] radiator shutdown on reload

[Martin Burton]

Just my 2p worth :-)

> 
> The error i created was only a typo in an include statement filename.  so, 
> the only error is really a 'file not found' type error.  i wouldn't think 
> this would be reason enough to shut down.
>

Unless someone is willing to go through every possible failure scenario
and identify whether such a failure should warrant a shutdown or not
then there's no way that Radiator can decide.  The safest thing is to
shutdown on *any* error, otherwise you could end up with a configuration
that doesn't work the way you expect it to.  I know it's possible to end
up with the same result even with a "correct" config, but shutting down
if Radiator can actually detect an error seems by far the safest option
to me.

If your environment is mission-critical then the answer is to always
pre-stage your configuration changes in a test environment that matches
your live environment.  At least that way you can be sure that a simple
typo isn't going to screw you over.  With the plethora of virtualisation
solutions that are available these days there isn't really an excuse for
not building a replica and testing stuff before you try it out.  I'm
sure that Mike and Hugh etc wouldn't begrudge you using an extra copy of
radiator beyond your license agreement for this kind of purpose? (we're
lucky in that we haven't used up our licensed instance allocation)


> Also, there is nothing in my log about the error.  The only time i seen 
> the error was on the cli when trying to start radiator back up again.  It 
> would be nice if radiator didn't shut down on error, but if it must, i 
> would think the last line in the log would be why it shut down.
> 
> I guess since it can't parse the config during the startup, it doesn't 
> know where/how to log, so the best time to log such an error is before it 
> shuts down, while it still has config of where the log file is.
>

I've generally found that Radiator is exceptional at telling me exactly
where I've stuffed up a configuration.  Having said that however, I
generally tend to bump up the log level to max and SIGHUP the server
before I make any further changes.  Perhaps doing the same might help
for you?

Cheers,

Martin


-- 
Martin Burton
Senior Systems Administrator               \\\|||///
Special Projects Team                     \\  ^ ^  //
Wellcome Trust Sanger Institute            (  6 6  )
-----------------------------------------oOOo-(_)-oOOo---
                                  http://www.sanger.ac.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://www.open.com.au/pipermail/radiator/attachments/20110603/21980b40/attachment.bin