Debugging the dodgy network... On the current running system (cheated on the systemd entry :-) ):
By default, the journal stores log data in
Tried that. Let's see if there are any more entries and if they survive a reboot!
I note that no entries have appeared in that directory yet... I wonder if I have to do something more?
Update: I edited /etc/systemd/journald.conf to change the Storage=volatile to Storage=persistent, then did systemctl restart systemd-journald.service to restart the logging with non-volatile storage. Hurrah - works!
Update:
The router log has the following entries around the time of the last outage (relevant bold):
That doesn't tell me a lot, but at least they agree! And there is no apparent fault with the router. I do note that my phone gets a lot of IP address assignments, at sub-10 minute intervals, which I notice. Maybe the signal is bad for that?
As an experiment, I might try plugging in the network extender I have and using that to provide a wired interface, to see if that makes a difference. The office RPi is using one of those and has no wired problem, although the wireless connection does fail a lot, despite using the wireless extender in the same room!!!
Update 2017-02-28:
Well, the link has been up now for 64 hours, without failing, using the Powerline network extender and a new, short Cat5 cable. This is positive. Maybe it's like my N years spent complaining about the laser printer's inadequacy and the uselessness of the drivers, when it was the cable all along...
[root@Frontroom ~]# journalctl --output=short-iso | grep "eth0: carrier lost"
2017-02-22T18:35:43+0000 Frontroom systemd[1]: Time has been changed
2017-02-24T04:35:42+0000 Frontroom dhcpcd[677]: eth0: carrier lost
2017-02-25T20:28:51+0000 Frontroom dhcpcd[677]: eth0: carrier lost
giving about 143,589 and 122,399 seconds between events. The lease is for 86400 seconds.
Annoyingly the Rune image clock starts on 22 Feb 2016, which is annoyingly close to the current date (25 Feb!). The --output=short-iso is required to display the year on the clock...
More data required... so I need to make the journal files non-volatile...
/run/log/journal/. Since /run/ is volatile, log data is lost at reboot. To make the data persistent, it is sufficient to create /var/log/journal/ wheresystemd-journald will then store the data:mkdir -p /var/log/journal systemd-tmpfiles --create --prefix /var/log/journal
Tried that. Let's see if there are any more entries and if they survive a reboot!
I note that no entries have appeared in that directory yet... I wonder if I have to do something more?
Update: I edited /etc/systemd/journald.conf to change the Storage=volatile to Storage=persistent, then did systemctl restart systemd-journald.service to restart the logging with non-volatile storage. Hurrah - works!
Update:
The router log has the following entries around the time of the last outage (relevant bold):
[DHCP IP: (192.168.1.16)] to MAC address 00:BB:3A:33:62:DA, Saturday, Feb 25,2017 20:35:46 [DHCP IP: (192.168.1.3)] to MAC address B8:27:EB:25:C4:1A, Saturday, Feb 25,2017 20:28:53 [UPnP set event: Public_UPNP_C3] from source 192.168.1.11, Saturday, Feb 25,2017 20:25:28 [UPnP set event: Public_UPNP_C3] from source 192.168.1.11, Saturday, Feb 25,2017 20:10:27 [Time synchronized with NTP server] Saturday, Feb 25,2017 20:09:33 [Internet connected] IP address: 192.168.0.3, Saturday, Feb 25,2017 20:08:45 [UPnP set event: Public_UPNP_C3] from source 192.168.1.11, Saturday, Feb 25,2017 19:55:28 [UPnP set event: Public_UPNP_C3] from source 192.168.1.11, Saturday, Feb 25,2017 19:40:27 [Time synchronized with NTP server] Saturday, Feb 25,2017 19:38:43
That doesn't tell me a lot, but at least they agree! And there is no apparent fault with the router. I do note that my phone gets a lot of IP address assignments, at sub-10 minute intervals, which I notice. Maybe the signal is bad for that?
As an experiment, I might try plugging in the network extender I have and using that to provide a wired interface, to see if that makes a difference. The office RPi is using one of those and has no wired problem, although the wireless connection does fail a lot, despite using the wireless extender in the same room!!!
Update 2017-02-28:
Well, the link has been up now for 64 hours, without failing, using the Powerline network extender and a new, short Cat5 cable. This is positive. Maybe it's like my N years spent complaining about the laser printer's inadequacy and the uselessness of the drivers, when it was the cable all along...
No comments:
Post a Comment