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.
truncateto 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:20ps. 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