2

I am trying to empty my syslog.1 file which was flooded with some messages and has the size of 77 GB. I did

sudo truncate -s 0 /var/log/syslog.1

but the command is taking more than 2 hours to return. Is it safe to stop it by Ctrl-C or by the kill command? I am afraid that these methods may cause inconsistency in the file system. Is there a better way?

The system is Ubuntu 16.04. The root partition where /var/log/syslog.1 sits is almost full due to the sudden increase in size of this file as well as /var/log/syslog and /var/log/kern.log. The latter files are still continuing to grow, but the command line is still responsive.

2
  • 2
    I would have expected truncate to have taken just a fraction of a second. Even on a file that large (because of caching). There's something else going on here – roaima Aug 3 '20 at 16:20
  • I looked at the process by ps. It was in the suspended (D+) state and 0:00 time was spent. I ended up shutting down the system without killing the process or doing anything on it. After booting it up again, I was able to run the command, and it returned in a second. I don't know what was the right thing to do, but so far the system looks running without problem. – norio Aug 3 '20 at 17:46
3

Interrupting a process will never cause the filesystem itself to become corrupted¹. The kernel ensures this. The worst that can happen is that the files are in an inconsistent state with respect to application invariants. For example, killing a file editor while it's saving the file may leave a half-written file, but won't damage other files.

The truncate utility calls the ftruncate system call under the hood. This system call is atomic: it either happens, or doesn't. So if you kill the truncate process, the end result is that either the file is in its original state as if truncate had not been run, or the file is truncated. You can't end up with a shortened but not fully truncated file.

Truncating a file doesn't overwrite the data on the disk. It only updates the list of blocks used by the file and the list of free blocks. It doesn't update the data blocks themselves: they'll be overwritten when they're reclaimed to store data later. Even with a large file, that wouldn't take long. And even overwriting 77 GB of data wouldn't take hours on any hardware where you're likely to have room for 77 GB of logs. So it's likely that something bad is happening. You may have hit a pathological case with bad performance on a full disk, but even so I would expect that to slow the system down for seconds, or minutes if something else is writing to the disk with high priority, but not hours. A more likely possibility is that there's something wrong with the disk, and that it's mostly a coincidence that it's revealed now. Check the kernel logs: if there's something wrong with the disk, you'll see messages about it. Also check the disk status with smartctl.

By the way, syslog.1 is an archive file, so nothing else is going to write to it. You might as well remove it rather than make it empty.

¹ Unless there's a kernel or hardware bug, but that could happen regardless of whether you kill a process.

1
  • Might mention logrotate etc. as another method (ideally syslog process gets reloaded to start writing a new file and you then delete the old one). – Will Crawford Aug 5 '20 at 3:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.