On Sun 07 Jul 2019 at 00:57:58 (-0400), Gene Heskett wrote: > On Sunday 07 July 2019 00:11:43 David Wright wrote: > > On Sat 06 Jul 2019 at 18:14:04 (-0400), Gene Heskett wrote: > > > On Saturday 06 July 2019 15:35:10 Brian wrote: > > > > On Fri 05 Jul 2019 at 21:35:25 -0400, Gene Heskett wrote: > > > > > On Friday 05 July 2019 15:23:38 Brian wrote: > > > > > > I was rather hoping someone would clarify why not having > > > > > > avahi-daemon in the first place was a good thing in general. > > > > > > Your problem doesn't particularly interest me because it is > > > > > > probably something you have brought on yourself due to > > > > > > previous actions. > > > > > > > > > > > > > Here is your Clarification: I used apt to purge avahi-daemon > > > > > > > which took nsswitch with it, > > > > That was your claim. Then I read the following: > > > > Greg> Whatever Gene did, it's absolutely not normal or desirable for > > Greg> nsswitch.conf to vanish. I still think he deleted it by hand > > and then Greg> forgot the exact sequence of steps which led to its > > disappearance, so Greg> he simply blamed it on purging ahavi-daemon. > > > > Gene> I didn't say that. If I made that impression I didn't intend > > to. I Gene> removed it by hand about 2 hours back but that u-sd has > > not been Gene> inserted in the pi yet as I'm also the chief cook […] > > Gene> […] recycle the dishwasher. :( > > > > https://lists.debian.org/debian-user/2019/07/msg00306.html > > > > > > > > I stopped reading there. I am not into fantasy. > > > > > > > > > > Which proves another theorem of mine. Folks with a sheepskin on > > > > > the office wall stop learning, and by your stopping without > > > > > reading the explanation is evidence of that effect. I can lead > > > > > you to the facts, but > > > > > > > > Your first "fact" is demonstrably incorrect and has been shown to > > > > be so. Indeed, you seem to have backed away from your claim that > > > > avahi-daemon is the cause of your difficulties. The only place you > > > > lead people is up the misleading garden path. A clear statement of > > > > what you did and what happened is more likely to bring results; > > > > making attacking software a lifestyle choice gets a bit boring > > > > after a while. > > > > > > > > > like the horse refusing to drink when led to water, I'll drop > > > > > the reins. You may, or may not drink the water of knowledge. I > > > > > can't control that. > > > > > > > > Is this an attempt at some self-promotion as the fount of > > > > knowledge? I never thought I would live to see the day! > > > > > > If you read the full thread, you will find where I found and fixed > > > that problem, by killing dhcpd5 with htop, and restarting > > > networking, and the problem was fixed, everything then worked > > > correctly, but I have not reinstalled avahi-daemon to see if it > > > returns. Perhaps I should because it appears there were 2 sources > > > of that trash. > > > > Perhaps you mean dhcpcd5? I thought you said that you're "the last one > > on the planet using hosts files and no dhcpd's of any kind". > > > That last as a qualifier was a bad reference too, as I now see the name > of that function having been changed sometime in the last 20 years. > > > If you were running this, did you try using the -L or --noipv4ll > > option? > > No, and whereintunket would I find that in reference to my problem?>
As you might guess, I don't have dhcpcd5 installed and have no interest in it, so I typed man dhcpcd5 into google. Kind of obvious really. > > > Yes, I purged what was left as it wouldn't reinstall, then > > > reinstalled avahi-daemon. results: > > > > > > With avahi-daemon running. the trash in the ip a report was back > > > after a networking restart, BUT allthough it showed in an ip r > > > report with a metric of 202, I could still ping yahoo.com. I could > > > not before. > > > > > > So I service avahi-daemon stopped it, and restarted the networking, > > > trash 169.254 junk gone. An yahoo.com still pinged. > > > > > > So I've purged it again. And restarted the networking yet again. > > > ip a: > > > pi@picnc:~ $ ip a > > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN > > > group default qlen 1000 > > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > > inet 127.0.0.1/8 scope host lo > > > valid_lft forever preferred_lft forever > > > inet6 ::1/128 scope host > > > valid_lft forever preferred_lft forever > > > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast > > > state UP group default qlen 1000 > > > link/ether b8:27:eb:d3:47:2d brd ff:ff:ff:ff:ff:ff > > > inet 192.168.71.12/24 brd 192.168.71.255 scope global eth0 > > > valid_lft forever preferred_lft forever > > > inet6 fe80::8815:60eb:fe0a:d5bc/64 scope link > > > valid_lft forever preferred_lft forever > > > 3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc > > > pfifo_fast state DOWN group default qlen 1000 > > > link/ether b8:27:eb:86:12:78 brd ff:ff:ff:ff:ff:ff > > > > > > ip r: > > > pi@picnc:~ $ ip r > > > default via 192.168.71.1 dev eth0 onlink > > > 192.168.71.0/24 dev eth0 proto kernel scope link src 192.168.71.12 > > > > That looks very like what I posted, except for "onlink"; also I'm > > connected by wireless rather than wire. But my ps -ef listing > > and nsswitch.conf file show: > > $ ps -ef | grep avahi | grep -v grep ; grep hosts /etc/nsswitch.conf > > avahi 653 1 0 21:23 ? 00:00:00 avahi-daemon: running > > [wren.local] avahi 666 653 0 21:23 ? 00:00:00 > > avahi-daemon: chroot helper hosts: files mdns4_minimal > > [NOTFOUND=return] dns > > > > > > So I now have a working network. Free of the bogus inventions of > > > dhcpd5 and avahi. That _was_ the point of all this hoopla in the > > > first place. > > > > > > Now, I have learned what works to _my_ satisfaction. > > > > Glad to hear it. I still don't see that you've shown why you had to > > purge avahi to get your results above. > > > > > Have you? Or did you quit reading the instant I went off the edge of > > > your menu? > > > I ask because I've since found that if I give avahi a chance to pollute > things, removeing it does no good until you've rebooted the machine and > I have already found that out for dhcpcd5. Either one can pollute, but > to get the full effect of removing it, you must reboot the machine. > However I am reticent to do that as I then have to go to the machine and > hand start ssh as it won't start on reboot even if told to. > > Why is that? I have had no such trouble with a realtime stretch. As I said before: Dunno. What does journalctl tell you? Cheers, David.