Yesterday I had to repair a light switch, and so power had to be taken off – and I expected that the datacentre would powered: the guide sheetÂ stated “First floor” and did not mention the attic where the datacenter is. Alas – that’s correct where lightÂ is concerned but major power is wired to the first floor – so DOWN all went.
Nasty thing is I just found out today. That is: KimÂ complained that Internet connectivity didn’t work. But the local network seemed Ok. It was impossible to access the system directly (I was on another location) so I got into the issue tonight – and found out what happened.
On Irene – the Windows machine for ‘normal use’Â – nslookup of an external site failed, but internal all was well. So I took a look to DIana’s TCPIP$BIND process – which was running fine but $ TCPIP SHOW HOST just showed the local database, not what is stored in DNS! So I restarted BIND (that is: $ @SYS$STARTUP:TCPIP$BIND_SHUTDOWN followed by $ @SYS$STARTUP:TCPIP$BIND_STARTUP) and next the data did properly show up. Next I had to renew Irene’s DHCP data, before nslookup did work.
But to find out WHY this happened: $ SHOW SYSTEM/NOPROC showed an uptime of only almost 24 hours, and yesterday’s Operator.log ended when I switched off power: at 19:15, and a second log started when power was restored (at 19:45). That’s a way to find out what miistake I made last night!
(If I could have checked the logfiles from my job location, something I usually do at another site, I would have noticed before)
Everthing worked fine after that, except for this blog. Simple reason: the logical where this log resides wasn’t properly defined. Just had to change that (manually, to be done in the startup files as well). Now all runs fine, only it seems mail is not delivered. I sent something this afternoon, there was nothing wong with it, it didn;t bounce but I have not got it here. It might come later…