[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /etc/init.d/networking does not start everything in /etc/network/interfaces



On Tuesday 17 May 2016 12:22:29 David Wright wrote:

> On Tue 17 May 2016 at 11:26:28 (-0400), Gene Heskett wrote:
> > On Tuesday 17 May 2016 10:38:52 Elimar Riesebieter wrote:
> > > * Gene Heskett <gheskett@shentel.net> [2016-05-17 09:56 -0400]:
> > > > On Tuesday 17 May 2016 09:08:55 tomas@tuxteam.de wrote:
> > >
> > > [...]
> > >
> > > > > In my opinion, a warning is in order ("this might not be doing
> > > > > what you think it does"), but deprecated seems exaggerated to
> > > > > me.
> > > > >
> > > > > [1] Schocking Truth! Not everything seen on the Internet is
> > > > > true!
> > > >
> > > > About 4th or 5th down in that list of hits, this one labeled for
> > > > debian, is a bit long winded  but finishes up recommending one
> > > > edit his personal .bash-aliases file to contain this:
> > > >
> > > > alias netrestart="sudo nohup sh -c 'invoke-rc.d networking stop;
> > > > date; echo sleeping; sleep 2; echo waking; date; invoke-rc.d
> > > > networking start'"
> > > >
> > > > Is that simple?  Elegant and correct?  No, if the networking
> > > > script was broken, its still broken!
> > >
> > > Again, I recommend to read [0] and [1].
> > >
> > > [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=550240
> >
> > Looks like mine has been "fixed" by the removal of the hotplug
> > stuff.  I do not see that as a disadvantage, udev can do that much
> > unwanted damage all by itself.
>
> I'm not sure what this has to do with your argument with udev.
> IIRC you had been switching cards and got up to eth5 when you posted.
> Apparently you hadn't read man udev, and though you said you'd scanned
> /etc/udev/rules.d/70-persistent-net.rules you didn't post it, so we
> couldn't point anything out. udev had been doing what it was designed
> to do.
>
> You don't see any disadvantage to removing the "hotplug stuff".
> Hooray, let's go back to PCs as static boxes. Shut it down to add
> a USB device. Who needs udev anyway?
>
Don't get too carried away, I was referring to the missing "hotplug" line 
in my interfaces file.  I didn't take it out. Out of 4 machines here, 
that line does not exist on any machine.

> > > [1]
> > > https://www.freedesktop.org/wiki/Software/systemd/PredictableNetwo
> > >rkInterfaceNames/
> >
> > And this falls over in its morning oatmeal if the box you installed
> > on turns out to be a dud, so you go  get another box and just move
> > the hard drive because you've already moved 20 megs worth of gcode
> > you don't want to do again if you reinstall on the newer box.  udev
> > remembers the old interface and very helpfully dreams up a new name
> > for it, without reaching into the interfaces file to correct the
> > port names there.  Or advising the user about it unless he goes
> > crawling thru the logs.  You get no warning other than the
> > networking can't be brought up that worked perfectly on the box with
> > an AMD Family 15 cpu with an unfixable halt bug because it doesn't
> > yet do a microcode update at the family 15 time point.  That
> > non-warned about renaming is not an excusable behavior. But it took
> > me 2 days to fix it each time I moved the drive because I had to
> > come here and hope for an answer each time.  I learned a lot thanks
> > to the kind folks here, but I fail to grok the reason for that
> > behavior in the first place.  Because of some rare condition, you
> > make all the other users with a less rare condition suffer?
>
> A previous time this reference was pointed out to you, you realised
> that it has no relevance to wheezy. Even if you upgrade to jessie,
> it's of little relevance as Debian preserves the existing behaviour
> if you don't try to wreck it/second-guess it/believe every posting on
> the internet.
>
> If you remember that far back, the linux kernel, faced with two NICs,
> would toss a coin before naming one eth0 and the other eth1. This had
> the splendid side-effect that you could think your LAN was the WAN and
> vice versa, and there was nothing you could do about it.

I ran the registered pc version of dd-wrt on an old K6-III box for 
several years, and not once did I observe the NIC's had been swapped on 
a reboot.  If linux ever had that problem I am unaware of it. And these 
were identical 100mbit nics.
>
> udev meant that each NIC always got the same name even if you took it
> out of the box one week and put it back the next. It is easy to
> override that behaviour if it's undesired.
>
> You appear to think that the old behaviour (the first NIC discovered
> gets named eth0) is the only sensible behaviour because everyone is
> always tinkering with the hardware, swapping boards out etc. as you
> do. If that is really important, why not just write a script to clean
> /etc/udev/rules.d/70-persistent-net.rules at every reboot.

Now thats a jolly good idea, so next time it has to start from scratch.
The point is however moot, I finally found a box that runs LCNC very 
well.  Not quite the latency results one can get from the long since out 
of stock intel D525MW motherboard, but that one can only do that one 
thing well as its out of both cajones and memory quickly if you want it 
to do more than that.  This box, a dell dimension 745, can run LCNC and 
do all the other stuff one needs to do at the same time. Without 
bothering LCNC, including running a hidef camera watching what the 
machine is doing and its video processing chain displayed on a separate 
workspace screen at the same time.

> That solves your problem, but allows other people to have a default
> system that can sensibly give a stable configuration on machines
> that have more than instance of each type of hardware (multiple
> NICs, burners, USB devices.

Only slightly valid today.  In fact since this install, my ups has 
remained on /dev/ttyUSB0 quite reliably even if I have moved cabling to 
put the same speed of device on a given exterior hub. I have several, 
and I've put the slow stuff on its own hub so the faster stuff can run 
at its full speed on a different hub. 5 years ago it was a problem.

I didn't intend to start a flamefest here, I was just asking for a little 
help with an edge case that only 2% will encounter in real life, but at 
the same time it has been educational, and different points of view have 
been well aired. But my instant problem HAS been solved, so lets put 
this one to bed for the time being?

> Cheers,
> David.

Thanks David & everybody else who replied.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>


Reply to: