I'm running a application using gnu screen and logging everything the the -L flag. The screenlog.n file is being created just fine. What I would like to copy the contents of that file to something like log_<date>, and then clear the screenlog.n file to start logging the next day. So far I have only found solutions for appending, or leaving the screenlog.n file to keep all the information.
I found that screen will create a new screenlog.n file automatically if I delete the existing one while a screen session is detached. I simply scheduled a cronjob to copy and rename the existing file and then delete it. A new screenlog.n file is created as soon as there is something new to log.
Related
I want empty a continuously printing log file in production,
I use below command:
echo > filename.log
I know the above command is used to empty continuously running log file if that file is getting too big.
But my query is - What happens to the old file?Does that file gets backed up or the previous data is lost forever?
How can I get the previous logs?
Previous data is basically lost forever.
You can search for backup files.There can be a file named filename.log~ for filename.log in the same directory.
It depends. If the other program has the log file permanently opened, the current log will be unlinked from its folder and your program just creates a brand new empty file. But the other program will still log to its now innaccessible file which will only be actually deleted when the program close it (or ends).
If the other program consistently uses the pattern open-write-close, you just erase previous content and new data will to that new file.
In any case old content is lost, but in first one the disk space is not reclaimed. If you want to keep it, you should google for log rotate
I have a process that is continually writing new files to a directory. When the current file reaches a certain size, it creates a new one with the timestamp. Like rolling log files, for example.
When the process closes the current file (A) and creates a new one, I would like to move A to a new directory for processing. I'm not sure of the best way to do this...
I wrote a bash script that runs every few minutes, lists all the files in the dir sorted by time, and moves all but the most recent. This works, but I can't help but feel like there is a better way, something more event-driven. I was looking at using inotifywait and capturing the CLOSE_WRITE,CLOSE event for the file ...
Any suggestions?
Thanks!
Found a better way. Using incron:
http://inotify.aiken.cz/?section=incron&page=why&lang=en
I using centos5.8
I wonder why syslog stop writing log after certain log edited.
for example, after cut the line of /var/log/messages, syslog doesn't write new log.
Just old logs are remained.
But If I delete the messages file and reboot the system, syslog works fine.
Is there any ways, syslogd write new logs continuosely after edit certain log??
It depends how exactly a file is edited.
Remember that syslogd keeps the file open for continuously writing. If your editor writes a new file with the old name after unlink()ing or rename()ing the old file, that old file remains in operation for syslogd. The new file, however, remains untouched.
It can be informed about the new file to be used with the HUP signal.
Well, that would depend on how syslogd works. I should mention that it's probably not a good idea to edit system log files, by the way :-)
You may have been caught out by one peculiarity of the way UNIX file systems can work.
If process A has a file open and is writing to it, process B can go and just delete the file (either with something like rm or, as seems likely here, in an edit session which deletes the old file and rewrites a new one).
Deletion of that original file does not destroy the data, it simply breaks the link between the file name (the directory entry) and that data.
A process that has the original file open can continue to write to it as long as it wants and, since there's no entry in the file system for it, you can't (easily) see it.
A new file with that file name may be bought into existence but process A will not be writing to it, it will be writing to the original. There will be no connection between the old and the new file.
You'll sometimes see this effect when you're running low on disk space and decide to delete a lot of files to clear it up somewhat. If processes have those files open, deleting them will not help you at all since the space is still being used (and quite possibly the usage is increasing).
You have to both delete the files and somehow convince those processes holding them open to relinquish them.
If you edited /var/log/syslog you need to restart the syslog service afterwards, because syslogd needs to open the file handle again.
My log files are generated inside a particular directory on my Linux server. Sometimes when I view the log files inside that directory using ls -lart, I see:
abc.log
.abc.log.swp
Could anybody please explain why the log file has the name .abc.log.swp?
Those are vim "swap" files -- temporary files created by vim while you are editing a file. They are (usually) removed automatically when you exit the editor.
When you edit a file using vi and some other editors, the editor creates a temporary swap file with the .swp extension. If something goes wrong and the editor crashes or the computer dies, the swap file contains your changes so you can revert back to the edited file.
As soon as you close the editor, the swap file should be deleted. If it isn't, and you didn't experience a crash, you can simply remove the swap file.
I am running a small inotify script that sets up a watch on a file. Each time that file is edited and saved, the script notices that a DELETE_SELF event is triggered. Is that normal and if it is why? Shouldn't the inotify subsystem notice that the file still exists?
It depends on what the application that is editing the file is doing with it. In this case, it sounds like the behavior of your editor when it saves a file is to delete the old file and write the new contents as a new file with the same name. From the perspective of inotify, this is exactly what happens, so it fires a deletion event and then a creation event. Inotify cannot know that the file that was deleted and the file that was created in its place are logically related.