On 07/12/17 12:09, Gordon Messmer wrote:> On 07/12/2017 07:13 AM, m.roth at 5-cent.us wrote: >> 4. It appears to try, several times, and then give up - as our >> manager puts it, "I to renew the lease", "Here it is","Nope, >> don't like that, try again", and eventually, after 4 or 5 or >> so tries, gives up. > > > NM tends to log fairly verbose information. It sounds like you've looked at > the network traffic. Have you looked at the logs on the affected systems? >Sorry, never got around to answering earlier, and we were all still looking. First, a correction: the same thing is happening on C6 servers. Next, there is *nothing*, not in dmesg*, not in /var/log/messages, to indicate when it failed, nor any failure message. No indication why the daemon didn't restart it. * Ok, I've got one good thing to say about C7: dmesg -H. Love it. mark
On Wed, 12 Jul 2017 19:22:20 -0400 mark <m.roth at 5-cent.us> wrote:> On 07/12/17 12:09, Gordon Messmer wrote: > > On 07/12/2017 07:13 AM, m.roth at 5-cent.us wrote:...> > NM tends to log fairly verbose information. It sounds like you've > > looked at the network traffic. Have you looked at the logs on the > > affected systems?...> Next, there is *nothing*, not in dmesg*, not in /var/log/messages, to > indicate when it failed, nor any failure message. No indication why > the daemon didn't restart it. > > * Ok, I've got one good thing to say about C7: dmesg -H. Love it.Maybe I can get that up to two good things... # journalctl -u NetworkManager # with optional -r for newest first Is rather convenient when looking for logs for a specific unit/service. A small added complexity is that there are two typically active units. "NetworkManager.service" and "NetworkManager-dispatcher.service" (.service can be omitted). /Peter
On 07/12/2017 04:22 PM, mark wrote:> On 07/12/17 12:09, Gordon Messmer wrote: >> On 07/12/2017 07:13 AM, m.roth at 5-cent.us wrote: >>> 4. It appears to try, several times, and then give up - as our >>> manager puts it, "I to renew the lease", "Here it is","Nope, >>> don't like that, try again", and eventually, after 4 or 5 or >>> so tries, gives up. >> > Next, there is *nothing*, not in dmesg*, not in /var/log/messages, to > indicate when it failed, nor any failure message. No indication why > the daemon didn't restart it.Where did your manager observe the conversation you described above? If you're watching traffic at the DHCP server, have you tried also capturing traffic on one of the affected clients? Following the failure, does the client have an IPv4 address and no IPv6 address? Or does it have an IPv6 address and no default route?
Gordon Messmer wrote:> On 07/12/2017 04:22 PM, mark wrote: >> On 07/12/17 12:09, Gordon Messmer wrote: >>> On 07/12/2017 07:13 AM, m.roth at 5-cent.us wrote: >>>> 4. It appears to try, several times, and then give up - as our >>>> manager puts it, "I to renew the lease", "Here it is","Nope, >>>> don't like that, try again", and eventually, after 4 or 5 or >>>> so tries, gives up. >>> >> Next, there is *nothing*, not in dmesg*, not in /var/log/messages, to >> indicate when it failed, nor any failure message. No indication why >> the daemon didn't restart it. > > Where did your manager observe the conversation you described above? If > you're watching traffic at the DHCP server, have you tried also > capturing traffic on one of the affected clients? > > Following the failure, does the client have an IPv4 address and no IPv6 > address? Or does it have an IPv6 address and no default route?No IPv6. IIRC, no default, either. mark
On 07/12/2017 04:22 PM, mark wrote:> On 07/12/17 12:09, Gordon Messmer wrote: >> On 07/12/2017 07:13 AM, m.roth at 5-cent.us wrote: >>> 4. It appears to try, several times, and then give up - as our >>> manager puts it, "I to renew the lease", "Here it is","Nope, >>> don't like that, try again", and eventually, after 4 or 5 or >>> so tries, gives up. >> > Next, there is *nothing*, not in dmesg*, not in /var/log/messages, to > indicate when it failed, nor any failure message. No indication why > the daemon didn't restart it.Where did your manager observe the conversation you described above? If you're watching traffic at the DHCP server, have you tried also capturing traffic on one of the affected clients?