🚀 go-pugleaf

rossc@extro.ucc.su.OZ.AU (Ross Cartlidge) writes:

>Due to a Power supply failure on the MHSnet (and anon ftp disk)
>at metro, MHSnet and anon ftp is not working.

>I should have a replacement by this afternoon.

>In the meantime metro is working much faster than normal :-)

The MHSnet disk power supply was fixed at 14:00 11/5.

I'd like to apologise for mail which was bounced
in the time between the failure and Monday morning.
This is what happened:-

Metro crashed at 8:55 on Saturday morning because disk failed.
It rebooted automatically and went all the way to multi-user
mode because fsck could even open the device (and thus didn't fail).

This meant that extro was running but the MHS stuff was not there
at all. I noticed this on Sunday, but didn't bring metro down
as I didn't want to lose non MHSnet services - which were working fine.

Unfortunately there was a flaw in this - sendmail fails badly
when the mailer it calls doesn't exist. This caused mail to get
bounced that was directed to MHS sites. When I was notified of this
problem (Thanks to Jim Richardson) I stopped sendmail to stop
mail from being accepted.

I have disabled auto-booting to solve this problem in the future -
does anyone know anything I could do to sendmail to make it
behave differently in this situation.

Sorry about the problems.

rossc
-- 
________________________________________________________________________
Ross Rodney Cartlidge			    |   rossc@extro.ucc.su.oz.au
University Computing Service, H08	    |   Phone:     +61 2 6923497
University of Sydney, NSW 2006, Australia   |   FAX:       +61 2 6606557

In <rossc.705659410@extro.ucc.su.OZ.AU> rossc@extro.ucc.su.OZ.AU (Ross Cartlidge) writes:

>rossc@extro.ucc.su.OZ.AU (Ross Cartlidge) writes:

->This meant that extro was running but the MHS stuff was not there
->at all. I noticed this on Sunday, but didn't bring metro down
->as I didn't want to lose non MHSnet services - which were working fine.

->Unfortunately there was a flaw in this - sendmail fails badly
->when the mailer it calls doesn't exist. This caused mail to get
->bounced that was directed to MHS sites. When I was notified of this
->problem (Thanks to Jim Richardson) I stopped sendmail to stop
->mail from being accepted.

->I have disabled auto-booting to solve this problem in the future -

This is a little extreme is it not?  Why not include some contingency tests
in your boot time startup code and only start sendmail if those tests are
satisfactory?  The existance of the MHS program that your sendmail invokes
would be a good one to deal with the above problem.

In article <rossc.705659410@extro.ucc.su.OZ.AU> rossc@extro.ucc.su.OZ.AU (Ross Cartlidge) writes:
>Unfortunately there was a flaw in this - sendmail fails badly
>when the mailer it calls doesn't exist. This caused mail to get
>bounced that was directed to MHS sites. When I was notified of this
>problem (Thanks to Jim Richardson) I stopped sendmail to stop
>mail from being accepted.
>
>I have disabled auto-booting to solve this problem in the future -
>does anyone know anything I could do to sendmail to make it
>behave differently in this situation.

I can think of one solution that you could have used if you were
running a version of sendmail that supported BSMTP (IDA sendmail for
example).  for the duration of the outage, you could have changed the
MHSnet mailer to write out BSMTP batches instead of passing them
into MHSnet.

When MHSnet came back up, you could change the MHSnet mailer back to
normal and give sendmail the BSMTP batches to process.  All the
messages should be reprocessed and passed to the MHSnet mailer, only
this time for real.

The only drawback I can think of is that there would be two Received:
headers in the message for your site, one from when it originally
arrived and the other when it was reprocessed.  I don't think this
would cause any major problems.  Perhaps some messages might exceed the
maximum hops but they would probably have been marginal anyway.

I haven't ever tried this so caveat utilitor.

	Ben.

daved@cortex.physiol.su.oz.au (Dave Davey) writes:

>In <rossc.705659410@extro.ucc.su.OZ.AU> rossc@extro.ucc.su.OZ.AU (Ross Cartlidge) writes:

>>rossc@extro.ucc.su.OZ.AU (Ross Cartlidge) writes:

>->This meant that extro was running but the MHS stuff was not there
>->at all. I noticed this on Sunday, but didn't bring metro down
>->as I didn't want to lose non MHSnet services - which were working fine.

>->Unfortunately there was a flaw in this - sendmail fails badly
>->when the mailer it calls doesn't exist. This caused mail to get
>->bounced that was directed to MHS sites. When I was notified of this
>->problem (Thanks to Jim Richardson) I stopped sendmail to stop
>->mail from being accepted.

>->I have disabled auto-booting to solve this problem in the future -

>This is a little extreme is it not?  Why not include some contingency tests
>in your boot time startup code and only start sendmail if those tests are
>satisfactory?  The existance of the MHS program that your sendmail invokes
>would be a good one to deal with the above problem.

I am not going to have contingency tests - for every possible
thing that can go wrong with the system - sounds like the "Halting
Problem" to me.

If the system crashes - it usually means there is something
wrong with the system (in this case a broken power supply).
I have always thought that auto-booting is a bit like the PC
solution to a bad operating system - use <CNTL><ALT><DEL>.

Of course, there are valid uses for auto-booting - like
power failures - but these are very rare.

rossc
-- 
________________________________________________________________________
Ross Rodney Cartlidge			    |   rossc@extro.ucc.su.oz.au
University Computing Service, H08	    |   Phone:     +61 2 6923497
University of Sydney, NSW 2006, Australia   |   FAX:       +61 2 6606557