File write buffering in Shell script

I have a start up shell script which reads a value from the file, increments it by 1 and writes it back. After that I do power-cycling of the system(switch off and switch on the power supply). I am trying to record the number of reboots using this way. But I find that the file counter always remains at 1. If I do the reboot using the reboot command, the counter in the file increments properly. Is this because the file write is buffered and delayed by the kernel. Is there a way to force it to write immediately?

The rc.us开发者_运维知识库er file is as follows:

cd /root
bash bootcounter.sh
sleep 1

bootcounter.sh is as follows

rebootcount=$(<bootcount)
rebootcount=$(($rebootcount+1))
echo $rebootcount >bootcount

Thanks...

You want the sync command. This should flush all the file systems.

count=$( cat bootcount )
echo $( expr $count + 1 ) > bootcount
sync

You should probably use a full path to bootcount, though.

There's no simple and unified answer for syncing file operation in filesystem - it's all very filesystem-dependent. For example, in fact, there could be no force writing, as there could be no writing at all - if we're talking about purely virtual system - or there could be multiple layers of writing, if we're talking about some network-exported file system.

There are a few things you can try, but generally, "your mileage may vary":

• There's one common way to make file system permanent state consistent - umount it. Most Linux distros unmount all filesystems during shutdown process and it ensures their clean and fully-dumped-to-hardware-drive state.
• If umounting is not an option, may be you can at least remount it as read-only - it effectively does the same shutdown procedures as unmounting, but leaves filesystem accessible - something like mount -o remount,ro /YOUR-FILE-SYSTEM
• If these are not possible, you can try running sync, but it has it's own glitches:
  • sync call is just an advice for filesystem, not a strict command
  • sync call may start syncing, but syncing itself takes some time; there's no way to know when syncing is finished
  • sometimes adding stuff like sleep 5 to sleep for 5 seconds to let the disc do the syncing helps
  • sometimes people using workaround like sync; sync; sync which is kind of reported to help in some mysterious way too
• You might want to also try emptying the cache: echo 3 >/proc/sys/vm/drop_caches - it will also force dumping of cache that should be written, but it also takes time and there's no way to know if it's finished. Sometimes combinations of all methods work, i.e:

sync; sync; sync
sleep 5
echo 3 >/proc/sys/vm/drop_caches

try:

rebootcount=`expr $rebootcount + 1`
echo $rebootcount >bootcount

or more simply:

echo `expr $rebootcount + 1` >bootcount

This information is already being tracked! Use the following:

last reboot  

Which lists all of the previous system boots since the file /var/log/wtmp was created. In addition, it tells you how long the server was up, at what time it went up and went down.

Looks like this:

reboot   system boot  2.6.35.10-74.fc1 Sun Jan  9 11:19 - 11:48  (00:28)    
reboot   system boot  2.6.35.10-74.fc1 Sun Jan  9 05:27 - 05:45  (00:17)    
reboot   system boot  2.6.35.10-74.fc1 Sat Jan  8 05:30 - 09:43  (04:12)

Just saying.