Please note that I dont have logrotate either syslogd in my system. I have simple klogd logs messages to a file.
Without stopping klogd, I simply copy the log file to a backup place, and empty the log file with echo > log_file.
The problem I have after I did that, when klog put next message into the log file, it also add alot of invisible char in the front of the file.
Any one knows how to get rid of it?
I do not want add more tools into my system.
Ask Try mv logfile newdestination
Next logentry from syslogd generates new logfile. A.
ask wrote:
If I did mv logfile newdestinatin, which means I delete the logfile. I think I should keep the file existence.
If I delete it, klogd never put anything into the new file. BTW I do not have syslogd in my system.
klogd will continue to write to the file - no matter how the name has changed. It's writing to a file handle, not the file name. This is why deleting the file ALSO has no effect until the process that has the file open actually closes it.
Have you tried that?
Old guy
If you mv file someelse. The file no longer exist. How klogd can write to it? I did not work. I think I have to live with those charactors at the front of file. Porblem is they "next line", and there are more than 1 k of them.
The problem is that you were truncating the file without killing and restarting klogd. That's no worse that the race condition between making a copy of the log and when the truncation was done. Since klogd has an open file descriptor during the truncation, it knows that it was writing at byte 56,789* of the logfile, and the next message will be written at that byte. The file will have a hole from byte 0 to 56,788. I'm surprised that there were anything but null characters in that space. Depending on the underlying filesystem, the space for that hole could be allocated when the first write happens, when the first read after of the hole, or not at all. If space is allocated, you have done nothing to shrink the file.
If you don't want to use syslogd, I suggest killing klogd, moving the file, and then restarting klogd. I believe the kernel has a reasonably sized buffer, so that you shouldn't even lose log messages during this, unless you have a lot of log messages. Your method has a race condition between copying the file and truncating the file where log messages could be lost.
-- John Haller
The concept is the same as 'unlink (2)'. The application that is using a file only cares about the file name when it begins using the file. There after, it's referring to a file handle that points to the file on the disk. You can you can delete the file, or move it, and the application does not know this - and does not care. It's still writing to those blocks on the disk.
The "normal" mechanism is to stop and restart the application that is writing to the file. You could also try sending the application a -HUP signal, which may cause it to re-read things - including the filename. This might be as simple as 'killall -HUP klogd' after you truncate the file.
Old guy
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.