[Kernel-packages] [Bug 1800888] Re: interfaces repetitively deleted in apparent synchrony with up/down network interface seesawing
Output from: apport-collect 1800888 The authorization page: (https://launchpad.net/+authorize-token?oauth_token=75pw0d303tBwqrdbP96z_permission=DESKTOP_INTEGRATION) should be opening in your browser. Use your browser to authorize this program to access Launchpad on your behalf. Waiting to hear from Launchpad about your decision... ERROR: connecting to Launchpad failed: [Errno 13] Permission denied: '/home/mab/.cache/apport/launchpad.credentials' You can reset the credentials by removing the file "/home/mab/.cache/apport/launchpad.credentials" notebook:~ 42 % rm /home/mab/.cache/apport/launchpad.credentials rm: cannot remove '/home/mab/.cache/apport/launchpad.credentials': No such file or directory notebook:~ 43 % Changing to "Confirmed": apport-collect 1800888 failed, per output above. Use the logs in the tar file that "ubuntu kernel bot" claimed wasn't present. Ubuntu bot is the final one of many impediments to submitting reports that your bug process placed in front of me while I was missing sleep while hurdling over each one to get this bug to you. THE final one. I wash my hands of this. ** Changed in: linux (Ubuntu) Status: Incomplete => Confirmed -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1800888 Title: interfaces repetitively deleted in apparent synchrony with up/down network interface seesawing Status in linux package in Ubuntu: Confirmed Bug description: In Description: Ubuntu 18.04.1 LTS Release: 18.04 Occasionally an attempt to open a connection fails, or an attempt to transfer a file, or do something else that works by opening a socket fails. Other things that you would expect to proceed normally with an already opened socket continue to do so. That's the case with TCP, at least. One might draw a conclusion based on the log contents described below that it would probably not so be for UDP, but I haven't tried to verify that. Examining syslog reveals groupings of strange repetitive behavior as demonstrated in the 3 successive groups copied from syslog below. I'm not certain of exactly when this behavior first appeared. I don't know if it's related, but since it appeared, I have seen no more instances of a different anomalous interface network interface behavior (namely: the network being unavailable upon system resumption following system suspension, and requiring performance of at least once more system suspension in order to restore network connectivity) The following are the most concise extracts I could make from the logs to demonstrate the issue. See the attachment for more: Oct 31 00:07:57 notebook ntpd[5122]: Deleting interface #124 enp2s0, 192.168.0.215#123, interface stats: received=72, sent=72, dropped=0, active_time=211 secs Oct 31 00:07:57 notebook ntpd[5122]: Deleting interface #125 enp2s0, fe80::540b:bc14:dd5f:304f%2#123, interface stats: received=0, sent=0, dropped=0, active_time=211 secs Oct 31 00:07:57 notebook kernel: [16414.973867] atl1 :02:00.0: enp2s0 link is up 100 Mbps full duplex Oct 31 00:07:57 notebook NetworkManager[975]: [1540969677.5690] device (enp2s0): carrier: link connected Oct 31 00:07:59 notebook ntpd[5122]: Listen normally on 126 enp2s0 192.168.0.215:123 Oct 31 00:07:59 notebook ntpd[5122]: Listen normally on 127 enp2s0 [fe80::540b:bc14:dd5f:304f%2]:123 Oct 31 00:12:42 notebook kernel: [16699.579883] atl1 :02:00.0: enp2s0 link is down Oct 31 00:12:43 notebook ntpd[5122]: Deleting interface #126 enp2s0, 192.168.0.215#123, interface stats: received=87, sent=88, dropped=0, active_time=284 secs Oct 31 00:12:43 notebook ntpd[5122]: Deleting interface #127 enp2s0, fe80::540b:bc14:dd5f:304f%2#123, interface stats: received=0, sent=0, dropped=0, active_time=284 secs Oct 31 00:12:43 notebook kernel: [16701.175235] atl1 :02:00.0: enp2s0 link is up 100 Mbps full duplex Oct 31 00:12:43 notebook NetworkManager[975]: [1540969963.7701] device (enp2s0): carrier: link connected Oct 31 00:12:45 notebook ntpd[5122]: Listen normally on 128 enp2s0 192.168.0.215:123 Oct 31 00:12:45 notebook ntpd[5122]: Listen normally on 129 enp2s0 [fe80::540b:bc14:dd5f:304f%2]:123 Oct 31 00:13:09 notebook kernel: [16726.743280] atl1 :02:00.0: enp2s0 link is down Oct 31 00:13:10 notebook ntpd[5122]: Deleting interface #128 enp2s0, 192.168.0.215#123, interface stats: received=20, sent=20, dropped=0, active_time=25 secs Oct 31 00:13:10 notebook ntpd[5122]: Deleting interface #129 enp2s0, fe80::540b:bc14:dd5f:304f%2#123, interface stats: received=0, sent=0, dropped=0, active_time=25 secs Oct 31 00:13:10 notebook NetworkManager[975]: [1540969990.9253] device (enp2s0): carrier: link connected Oct 31 00:13:10 notebook kernel: [16728.330285] atl1 :02:00.0: enp2s0 link is up 100 Mbps full duplex Oct 31 00:13:12 notebook
[Kernel-packages] [Bug 1800887] Re: launchpad is claiming my report has one error, but is not flagging what that error is
You may choose to cancel this bug. Or better, you may choose to fix (or at least warn about) the problem I am about to describe. The cause of the difficulty resulted from my having originally entered: "Network Manager and/or ntpd" under "In what package did you find this bug?". The page had flagged that, so per recommendation, I clicked "I don't know instead". However, because I did not erase the words "Network Manager and/or ntpd", when I clicked "Submit", the web page decided that I should have clicked on the button next to the words that I did not erase, so it re- clicked it for me and unclicked "I don't know", which re-introduced the page's recognition that I had made an error. Because I had explicitly clicked "I don't know", it hadn't occurred to me to consider that clicking "Submit" would have caused my most recently chosen answer to the "package" question to have been reverted to my previous answer by the page itself, on my behalf. I had already fixed the error I had made on that part of the page (or so I thought), so when another error was flagged, I looked everywhere else on the page to try to figure out what the page was complaining about. I understand that this may have arisen out of an idiosyncrasy in the implementation, but with that being the case, it would take only a few additional characters of code to detect what it could consider to be an "incomplete change" and provide some warning of its inability to handle the manner in which a human would normally and naturally be expected to correct the error I had originally made and corrected. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1800887 Title: launchpad is claiming my report has one error, but is not flagging what that error is Status in linux package in Ubuntu: Incomplete Bug description: launchpad is claiming my report has one error, but is not flagging what that error is I would try to enclose the report that it has the problem with, but it would flag that report as having one error, too, without flagging the error itself, so I don't know how to be specific about it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1800887/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1800888] [NEW] interfaces repetitively deleted in apparent synchrony with up/down network interface seesawing
Public bug reported: In Description: Ubuntu 18.04.1 LTS Release:18.04 Occasionally an attempt to open a connection fails, or an attempt to transfer a file, or do something else that works by opening a socket fails. Other things that you would expect to proceed normally with an already opened socket continue to do so. That's the case with TCP, at least. One might draw a conclusion based on the log contents described below that it would probably not so be for UDP, but I haven't tried to verify that. Examining syslog reveals groupings of strange repetitive behavior as demonstrated in the 3 successive groups copied from syslog below. I'm not certain of exactly when this behavior first appeared. I don't know if it's related, but since it appeared, I have seen no more instances of a different anomalous interface network interface behavior (namely: the network being unavailable upon system resumption following system suspension, and requiring performance of at least once more system suspension in order to restore network connectivity) The following are the most concise extracts I could make from the logs to demonstrate the issue. See the attachment for more: Oct 31 00:07:57 notebook ntpd[5122]: Deleting interface #124 enp2s0, 192.168.0.215#123, interface stats: received=72, sent=72, dropped=0, active_time=211 secs Oct 31 00:07:57 notebook ntpd[5122]: Deleting interface #125 enp2s0, fe80::540b:bc14:dd5f:304f%2#123, interface stats: received=0, sent=0, dropped=0, active_time=211 secs Oct 31 00:07:57 notebook kernel: [16414.973867] atl1 :02:00.0: enp2s0 link is up 100 Mbps full duplex Oct 31 00:07:57 notebook NetworkManager[975]: [1540969677.5690] device (enp2s0): carrier: link connected Oct 31 00:07:59 notebook ntpd[5122]: Listen normally on 126 enp2s0 192.168.0.215:123 Oct 31 00:07:59 notebook ntpd[5122]: Listen normally on 127 enp2s0 [fe80::540b:bc14:dd5f:304f%2]:123 Oct 31 00:12:42 notebook kernel: [16699.579883] atl1 :02:00.0: enp2s0 link is down Oct 31 00:12:43 notebook ntpd[5122]: Deleting interface #126 enp2s0, 192.168.0.215#123, interface stats: received=87, sent=88, dropped=0, active_time=284 secs Oct 31 00:12:43 notebook ntpd[5122]: Deleting interface #127 enp2s0, fe80::540b:bc14:dd5f:304f%2#123, interface stats: received=0, sent=0, dropped=0, active_time=284 secs Oct 31 00:12:43 notebook kernel: [16701.175235] atl1 :02:00.0: enp2s0 link is up 100 Mbps full duplex Oct 31 00:12:43 notebook NetworkManager[975]: [1540969963.7701] device (enp2s0): carrier: link connected Oct 31 00:12:45 notebook ntpd[5122]: Listen normally on 128 enp2s0 192.168.0.215:123 Oct 31 00:12:45 notebook ntpd[5122]: Listen normally on 129 enp2s0 [fe80::540b:bc14:dd5f:304f%2]:123 Oct 31 00:13:09 notebook kernel: [16726.743280] atl1 :02:00.0: enp2s0 link is down Oct 31 00:13:10 notebook ntpd[5122]: Deleting interface #128 enp2s0, 192.168.0.215#123, interface stats: received=20, sent=20, dropped=0, active_time=25 secs Oct 31 00:13:10 notebook ntpd[5122]: Deleting interface #129 enp2s0, fe80::540b:bc14:dd5f:304f%2#123, interface stats: received=0, sent=0, dropped=0, active_time=25 secs Oct 31 00:13:10 notebook NetworkManager[975]: [1540969990.9253] device (enp2s0): carrier: link connected Oct 31 00:13:10 notebook kernel: [16728.330285] atl1 :02:00.0: enp2s0 link is up 100 Mbps full duplex Oct 31 00:13:12 notebook ntpd[5122]: Listen normally on 130 enp2s0 192.168.0.215:123 Oct 31 00:13:12 notebook ntpd[5122]: Listen normally on 131 enp2s0 [fe80::540b:bc14:dd5f:304f%2]:123 Oct 31 00:16:30 notebook kernel: [16927.574126] atl1 :02:00.0: enp2s0 link is down While not scientific, I suspect the following view of the (brief enough to permit reliable TCP byte streams, as verified by md5sum) timing between "link down" and "link up" events (as opposed to the much longer amount of time elapsing between "link up" and the next down event) might help to explain why the problem is not more symptomatic than it is: [Oct30 20:23] atl1 :02:00.0: enp2s0 link is down [ +1.544088] atl1 :02:00.0: enp2s0 link is up 100 Mbps full duplex [Oct30 20:24] atl1 :02:00.0: enp2s0 link is down [ +1.630772] atl1 :02:00.0: enp2s0 link is up 100 Mbps full duplex [Oct30 20:32] atl1 :02:00.0: enp2s0 link is down [Oct30 20:33] atl1 :02:00.0: enp2s0 link is up 100 Mbps full duplex [Oct30 20:38] atl1 :02:00.0: enp2s0 link is down [ +1.626526] atl1 :02:00.0: enp2s0 link is up 100 Mbps full duplex [Oct30 20:42] atl1 :02:00.0: enp2s0 link is down [ +1.578927] atl1 :02:00.0: enp2s0 link is up 100 Mbps full duplex As before, this is brief, but enough to be illustrative, and more can be found in the tarred log info. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Tags: bionic ethernet frequent-seesawing interface link-down link-up seesawing ** Attachment added: "dmesg,loggreps.tar"
[Kernel-packages] [Bug 1800887] [NEW] launchpad is claiming my report has one error, but is not flagging what that error is
Public bug reported: launchpad is claiming my report has one error, but is not flagging what that error is I would try to enclose the report that it has the problem with, but it would flag that report as having one error, too, without flagging the error itself, so I don't know how to be specific about it. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1800887 Title: launchpad is claiming my report has one error, but is not flagging what that error is Status in linux package in Ubuntu: Incomplete Bug description: launchpad is claiming my report has one error, but is not flagging what that error is I would try to enclose the report that it has the problem with, but it would flag that report as having one error, too, without flagging the error itself, so I don't know how to be specific about it. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1800887/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
