5

I put my program in startup applications because of this. The directory /var/log is taking around 36 GB space.

Can I delete syslog and syslog.1 file which are taking the highest percentage of storage in /var/log directory?

Anwar
  • 76,649
limo_756
  • 61
  • 1
    Notice that 15.10 is no longer supported. Consider upgrading to 16.04. –  Aug 22 '16 at 12:57

1 Answers1

3

Of course you can...

But... normally, on a default Ubuntu, the system will clean up logs automatically using something called logrotate. By default it will logrotate daily (You can see that in /etc/logrotate.d/rsyslog)

Since they did become so large, you may want to see what is causing the log to become so incredibly large in less than 24h... There might be a significant problem, like a disk having a lot of errors. Perhaps take a look at the contents in real time for a while. To do that:

tail -f /var/log/syslog

To get back to your prompt, hit Ctrl-C.

jawtheshark
  • 2,522
  • 1
    "Of course you can..." nope ;-) – Rinzwind Aug 22 '16 at 13:36
  • 1
    Can you point me to an instance where they actually crash the service? Worst case, they have a lock on the file and you just empty them. A right out crash? No, never seen that on a Debian based system. So, point me to reproducible scenario where it will crash my service... Just saying it will is not good enough for me. – jawtheshark Aug 22 '16 at 13:42
  • Basically, there are two scenarios: a) The log file is locked and that means you cannot delete it. Or better said, you can, but due to being locked, the inode is kept in use and the process continues writing there. This means the directory entry is wiped (due to the rm), but the process still has a lock on the inode. The disk space will not be recovered until you restart the service. Typical examples of this are java daemons· b) The file is opened with each write to log file. In that case, deleting it will just cause it to be recreated on when the service logs something new. – jawtheshark Aug 22 '16 at 13:49
  • In my 7 years as Linux admin on mostly Debian based servers for a high traffic site, I've only seen those two. a) being the most annoying, but never, and I mean never, did removing a log file cause a crash. I'd consider a daemon crashing on a non-existing log file to be a bug. – jawtheshark Aug 22 '16 at 13:50
  • Well for one: deleting log files also delete permissions, username and group and lots of services are picky on those. Some need to be "adm", others "root", "mysql", "landscape". 2nd: when you delete a log it can't be written as log as it is deleted. You could miss viable information – Rinzwind Aug 22 '16 at 13:58
  • They managed to create these files in the first place, they should be able to re-create them when they are missing. If the process runs as root, it will always be able to create the missing file. The default group for /var/log/ is adm and it has rw rights, so any process running in the adm group can and will be able to create log files.

    Furthermore, if they can't write to a log any more, they still should fail gracefully by... not logging. The next logrotate is usually going to fix it, for example mysql has the statement create 640 mysql adm for its log files (see logrotate config)

     – jawtheshark Aug 22 '16 at 14:14