UNIX for Dummies Questions & Answers

so i was testing something on a test box running linux. i manually vi'ed the /var/log/messages file. and i noticed, the file immediately stopped being updated.

it wasn't until i restarted the syslog process that events started being recorded in it again.

so that tells me, the syslog process knows when that file is modified by a process other than itself, so that prevents it from working.

can someone please show me how i can apply this same tactic to a file of my own?

for instance, if i have a file called /home/skysmart/boldness.txt. I want to know whenever this file is "vi'ed" by a real life user or if someone other than a specific process adds contents to it, as in ">>" /">" .

I'm guessing that you're really saying that new lines being written to the log file did not show up in your vi editing buffer until you closed vi and reloaded the file. It is extremely unlikely that anything stopped writing to a file because vi had that file open.

When you edit a file using vi (or ex or ed or emacs or any other editor) you load a copy of that file into a buffer. You edit the buffer; not the underlying file. If you want to see recent additions to the file while you are editing it, you need to reload the buffer from the file. In vi, the command to reload the buffer is :e. If you have changed the buffer and have not written the updates back to another file; you'll need to use :e!. If you change the file and write those changes back to the file while some other process is writing to it, whether the changes you made to the file or additions added by that other process or some combination of those changes and additions will appear in the file after you exit vi is unspecified.

i'm pretty familiar with vi. what i was saying was that, apparently, when you vi a file thats being written to by syslog, syslog stops updating that file. yeah, when i vied that filed and saved it, i saw my additions in there. that wasn't the issue. the problem was, after my additions, i expected to have syslog continue to update the log file as usual. but no. it just stopped updating, until i restarted it.

this happened on linux red hat 6.2. i'm guessing most people aren't aware of this?

Try the following, and you will see that while you are editing the file, syslog continues to update the log file.

- go to the end of the file in vi and see what is there.
- wait a few minutes to let something loggable happen.
- in a separate window, do a tail on the log file.
- the results will be different, because syslog continues to update the file.

Here is another demo:

Code:

$ date > date.txt
$ vi date.txt # will see single line
$ date >> date.txt # in another window, while vi open
$ cat date.txt
Wed Apr 17 13:56:14 PDT 2013
Wed Apr 17 13:56:27 PDT 2013

When you saved the log file from within vi, you wiped out the changes that syslog had made. Normally, not a good idea to make changes to syslog log file, unless some over-riding benefit.

syslogd is not "prevented from working", and /var/log/messages is not "stopped being updated".

When you edit that file, AND save it, a new copy is created, of which syslogd does not know. It happily keeps logging to the old file, accessed via inode number, as you can see using the lsof command.
Send a HUP signal to the process to close and reopen all files.

That is incorrect. Whatever changes syslog had made are still there. When saving, vim unlinks the original file and creates a new one. syslog is still working with the original, as RudiC points out.

While the original file is no longer reachable through the filesystem, any process with an open descriptor to the original's contents can still read/write from/to it. Only when the last of those descriptor's is closed will the kernel remove the unreachable file.

From the POSIX unlink(2) manual:
To demonstrate this, let's use sed to delete all empty lines from a file, without using a temp file (-i, even when available, uses a temp file):

Code:

{ rm file; sed '/./!d' > file; } < file

1) { ... } < file opens a descriptor to the original file contents. As long as this descriptor is open, the original file's contents are accessible.
2) rm file unlinks the file. At this point, the file is no longer reachable through the filesystem hierarchy.
3) The redirection in sed ... > file creates a new file and redirects stdout to it. sed inherits its stdin descriptor from the parent sh, through which it has access to the original file's content.

Such "cleverness" is usually a very bad idea. Not creating the temp file means that, should the system fail at just the right time, you could be left without a reachable version of the data. And even though a temp file isn't created, the amount of storage required is the same (the original version of the file and the version without empty lines will coexist for some finite amount of time).

If instead an editor which does not unlink the original file were used, e.g. ed, there would then be the problem of multiple unsynchronized writers. The resulting file's contents will be some indeterminate, interleaved melange of data written by multiple processes.

Regards,
Alister

Addendum to the unlinked "old file, accessed via inode number": You could try and undelete the old file using (on linux systems!) debugfs:
man debugfs: The chance of finding all blocks intact is high as the file as such is still there and held open by the syslogd process. In fact, thinking twice, it should be 100%