My /var/log/ is mysteriously filling up GBs in minutes! Any cure before I re-install Debian 7?
There is actually a strong hint in the syslog
snippet you posted. The end of the line
Apr 10 00:53:37 MyMachine kernel: [11608.690733] [<ffffffffa08e4005>] ? ath9k_reg_rmw+0x35/0x70 [ath9k_htc]
shows the stack trace is due to an unexpected error in a device driver named ath9k_htc
. Hopefully, the kernel didn't panicked but the continuous repetition of errors is filling your file system.
I would then blacklist the ath9k_htc
wifi driver using this command then rebooting:
echo "blacklist ath9k_htc" | sudo tee -a /etc/modprobe.d/blacklist.conf
Beware though that doing so might prevent your wifi to work if the ath9k_htc
driver was nevertheless used and functional despite the errors.
You can check if a wifi device expected by the ath9k_htc
driver is present in your machine by running lsusb
and see if a device match one of the list available here: https://wiki.debian.org/ath9k_htc
You don't need to open the log files in an editor to see what's flooding them. Just look at the last few lines:
tail -n 999 /var/log/syslog | less
Log files from a process always contain the process ID:
Apr 10 00:00:01 harfang /USR/SBIN/CRON[345]: (root) CMD ( /usr/local/bin/midnight-stuff )
Apr 10 00:00:01 darkstar wibbled[1234]: I'm bored
Apr 10 00:00:01 darkstar wibbled[1234]: I'm still bored
Apr 10 00:00:01 darkstar wibbled[1234]: I'm bored
Apr 10 00:00:02 darkstar wibbled[1234]: I'm still bored
Apr 10 00:00:02 darkstar wibbled[1234]: I'm bored
This tells you that process 1234, which is an instance of the wibbled
daemon, is producing a lot of log messages. You may want to kill it and check its configuration.
If kern.log
is growing a lot, your logs aren't coming from a process but from the kernel. Flooding in the kernel logs is rarer and can be harder to pin down. It can be due to a process that's being respawned in a tight loop and is crashing immediately (perhaps due to low memory on the system). It can also be due to a buggy driver. You need to look at the messages to understand the cause.
In your case, you're seeing a backtrace from a driver. The driver is encountering a non-fatal error incessantly. Try unloading it:
rmmod ath9k
(Why ath9k
? Because that's the driver that provides the function ath9k_reg_rmw
, but actually because the module name would be mentioned a few lines further up from the bit you included in your question.) If the driver isn't in a module or cannot be unloaded, look for another way to disable it or stop triggering its bug; how to do that depends on what driver it is and what's wrong with it.