-3

I got the warning that I only have 38 MB of disk space left. The reason for this seem to be two huge log files: syslog.1 and kern.log.1 with 388 GB each.

I installed Linux Pop!OS only recently so my system is quite fresh. Before the problem happened I did two things which might have caused this problem:

  1. I updated the system.
  2. I tried to install a game (Alpha Protocol) using a DVD and Lutris. The installation seemed to freeze on the first DVD. After a while, the game asked for the second DVD. After entering the second DVD the installation seemed to freeze again. After several hours still nothing happened except the warning about the low disk space. I could not stop the installation so I restarted the computer.

I would like to know the following things:

  1. What can I do to find out what the problem was?
  2. How can I shrink these files?
  3. Is there a possibility to stop this from happening again? I Want to try installing the game again but I do not want to risk destroying my system due problems caused by running out of disk space.

I was a Microsoft Windows user my whole life and have therefore no clue about Linux. An answer would therefore need to be given in a way that even a lay person could understand it.

There are several other questions on this site concerning this problem. However, they are not helpful for me due to various reasons. For example

Very large log files, what should I do?

  • The accepted answer has a comment which makes me unsure whether it is wise to use this answer while being someone who does not really know what he is doing: "This answer does not adequately describe what you are supposed to do with lastlog, wtmp, dpkg.log, kern.log and syslog."
  • I do not think the accepted answer prevents the problem from happening again or lets me find the reason for this behavior.
  • The command from an other answer tail -n 100 /var/log/syslog does not produce an output which helps me find out what the problem is. There is also a longer command
for log in /var/log/{dmesg,syslog,kern.log}; do 
 echo "${log} :"
 sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
 | sort | uniq -c | sort -hr | head -10
done

which I do not understand what it is doing. Also I do not know whether it will for example produce a copy of the file or something which would be a problem on my already nearly full hard drive.

https://stackoverflow.com/questions/35638219/ubuntu-large-syslog-and-kern-log-files

  • The highest voted answer seems to criticize the accepted answer. One of the criticize points is the fact that the log files get deleted. However, I am not sure whether this is not also the case for the highest voted answer.
00koeffers
  • 95

1 Answers1

1
  • PopOS is off topic here, but the question is not
  • Normally logrotate moves large logfiles aside. If your log file is named syslog.1 this has already happened. On next rotation, it might get compressed. If there is space, you could manually compress it immediately. (Typically gzip -9 is used for this.)
  • The only way to determine why the log file is so large is to look at its contents and see what spewed errors into it. The errors may be transient and may not reoccur, or they may be something you can fix, silence, or move to another log file by adjusting rsyslog configuration.
  • In an emergency, since the log file has already been rotated, you can just delete it. If you still want to analyze it, you could copy it somewhere else (with more space) first. Presuming you can't compress it instead.
  • After you look at syslog.1 and determine what the major contributor was, you should look at syslog (which is the current live log file) and see if it is still complaining.
  • The complex for log... command you pasted goes through the most common live system log files, strips off the most common variable parts of the messages, and then sorts and counts the remainder, and then lists the top ten most common messages for each log file. (It prints this out to the screen, doesn't save anything.) As written, this only looks at the current live log files, not rotated ones, so it will likely miss your problem. You could extract out of this just the sed line and replace ${log} with syslog.1 ... or you could just use less and look at syslog.1 directly.
user10489
  • 5,533