[BlueOnyx:21468] Re: Bizarre 5209R loses network config
Chris Gebhardt - VIRTBIZ Internet
cobaltfacts at virtbiz.com
Tue Oct 3 16:46:21 -05 2017
Hi Michael,
On 10/3/2017 4:01 PM, Michael Stauber wrote:
> Hi Chris,
>
>> /etc/udev/rules.d/70-persistent-net.rules had two distinct MAC entries
>> listed for eth0. Two entries, just as you might expect when there are
>> 2 interfaces (typically eth0 and eth1) but both were eth0.
>
> This is pretty weird indeed. Just to clarify: The reported MAC addresses
> for eth0 were the same or were they different? If they were different,
> that would make it even weirder as the MAC address of an interface isn't
> supposed to change.
The MAC addresses were different. One of them wasn't even a MAC on the
system. I show that 5209R was installed on this system over a year ago,
and the hardware hasn't changed. So yeah - very weird.
>> the net.ifnames=0 variable. It was missing.
>
> All the 5209R ISOs do set the net.ifnames=0 during post install and
> during kernel upgrades these options are usually retained. I'm at a loss
> why this would go walkies on its own. :-/
I agree. Troubling. Puzzling.
> The likelihood of this to happen again is pretty small.
Which is good news.
> Fact of the matter is: Apache is a bitch to restart or reload
> non-interactively.
Recently, Apache has just plain been a bitch.
> We now run Swatch at the end of any YUM update that issues a CCEd rehash
> or restart and almost all BlueOnyx updates do one of these for good
> measure.
I've been following along there, and am looking forward to seeing that
in action. Or more accurately, not noticing! ;)
Honestly, overall the updates go pretty smoothly considering the number
of servers that are running under our care. It's interesting that if we
get a report of one box falling down, it's sometimes just a matter of
time before the "usual suspects" fall apart as well. But we've yet to
determine what, if any, commonality exists.
> There isn't much room for further improvement to that, unless I start
> over and use a radically different approach. I am considering turning
> Swatch into a daemon that performs health checks more often than the
> current 15 minute cronjob.
Interesting.
> There are a couple of reasons that in favor of such a daemon (and I
> haven't mentioned all of them yet), but also 2-3 that speak against it.
> I'd rather wait an see if the recent changes to Swatch and the YUM
> plugin take good enough care of the issue as is, before I set off to
> code the Swatch-daemon.
Yeah, I'm with you there. If it ain't broke, don't fix it. Also, a
daemon to watch the daemons... hmmm.
--
Chris Gebhardt
VIRTBIZ Internet Services
Access, Web Hosting, Colocation, Dedicated
www.virtbiz.com | toll-free (866) 4 VIRTBIZ
More information about the Blueonyx
mailing list