GNHLUG's Internet presence was offline for a few days, after I tried to restart udevd and the system immediately went dead-to-the-net. That was on Thursday. I got the system rebooted today. (The system has been so trouble-free since it was installed that nobody knew exactly where it was, which slowed down trouble-shooting attempts.)
What's interesting about this episode are: (1) I had just done the same on a system with roughly the same software configuration, and it didn't seem to have any trouble. (2) Checking logs after-the-fact, it appears the system was still running, after a fashion. I can only guess some part of the networking subsystem had become the notworking subsystem. The first I can chalk up to Finagle's Law[1], but the second is more curious. Selected log entries include the following: Sep 25 14:30:24 liberty sudo: bscott : TTY=pts/1 ; PWD=/home/bscott ; USER=root ; COMMAND=/sbin/start_udev Sep 25 14:30:30 liberty kernel: ADDRCONF(NETDEV_UP): eth1: link is not ready Sep 25 14:39:52 liberty ntpd[10892]: no servers reachable Sep 25 14:46:23 liberty sshd[10399]: Read error from remote host 65.96.245.47: No route to host Sep 25 14:46:43 liberty sshd[10397]: pam_unix(sshd:session): session closed for user bscott Sep 25 15:01:39 liberty named[12525]: client 162.212.181.242#26034: query (cache) 'wwww.jrdga.info/A/IN' denied Sep 25 17:47:06 liberty named[12525]: client 162.212.181.242#56665: query (cache) 'wwww.jrdga.info/A/IN' denied Sep 25 18:25:18 liberty named[12525]: client 162.212.181.242#37853: query (cache) 'wwww.jrdga.info/A/IN' denied The command at 14:30:24 is the one that ruined the parade for everybody. The entry at 14:30:30 makes some sense, as eth1 doesn't have anything plugged into it (the link is eth0). The fact that the system decided to log that then, however, seems significant. Perhaps the network driver/interface layer reset, and came back with defaults (no address)? Without anything to tell it otherwise, it would sit there forever, waiting to be configured with an IP address. The entries from 14:39 through 14:46, inclusive, are indicative of networking being broken and various things failing as a result. The entries at 15:01 onward I don't get. The DNS server logs them when a client's query is denied. Typically this is a client that's trying to use us as a recursive resolver, which we aren't and don't allow. This particular domain suggests it's part of a DNS amplification attack attempt, which means the source address is prolly spoofed. The part I don't understand is -- how did it get received in the first place, if the network was down? In the future, I won't try restarting udevd remotely. -- Ben [1] "The perversity of the universe tends towards a maximum." It is more flexible than Murphy's Law, as it allows for things to go right if by going right, that will lead to a larger problem later. Case in point. _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
