@MSGID: 1@dont-email.me> 7246219d
@REPLY: 2@dont-email.me> 4ff21aa6
@REPLYADDR Rich <rich@example.invalid>
@REPLYTO 2:5075/128 Rich
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
<ygamsxoixhx.fsf@akutech.de> 4@dont-email.me> <ygail8biyxm.fsf@akutech.de>
1@dont-email.me> <ygaedizitb9.fsf@akutech.de> 2@dont-email.me>
<yga4jjvik9o.fsf@akutech.de> 1@dont-email.me> 1@dont-email.me>
2@dont-email.me>
@TZUTC: -0000
@PID: tin/2.6.1-20211226 ("Convalmore")
(Linux/5.15.117 (x86_64))
@TID: FIDOGATE-5.12-ge4e8b94
In comp.os.linux.misc The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 15/09/2023 16:26, Rich wrote:
>> Are the "files" being written to by an independent process separate 
>> from this reading process?
>> 
> Yes
> 
>> If yes, are you doing any form of locking/synchronization to prevent 
>> the reading process from trying to read from a file that a writing 
>> process has open/truncated, but not yet written any data into?
>> 
> No.
> 
>> If no, then you may be also hitting a race condition where the stars 
>> align just right, the writer has just performed its fopen/truncate 
>> (leaving the file empty) and the kernel decides to context switch 
>> away to the reader at that point, before the writer can write and 
>> close the file.  The reader will then see an empty file.
>> 
> I think that is exactly the case.  I didnt think that was in fact 
> possible

It is.  One of the points where Linux evaluates to determe if it should 
task switch is upon exit from a syscall.  If your writer process runs 
out its timeslice during the in-kernel portion of the work for an 
fopen, then the kernel will suspend it and schedule another process to 
run.  You now have an empty, unwritten file on disk which will not be 
written to until the writer is next scheduled by the kernel.  If the 
next process scheduled is the reader, and it was last suspended just 
before it did an fopen() on this same file, it will now fopen() an 
empty file.

>> The classic "lock free" solution to this one is for the writer to
>> create and write to a temporary file, and after closing the temp file
>> to rename() it to the name of the real file.  Rename is documented to
>> be atomic, so the reader would never see a half open, or partially
>> complete, file in this case.
> 
> Yes, I was just wondering that before I read this post. Rename unlinks 
> the old file does it?

Yes: (man 2 rename):

   If newpath already exists, it will be atomically replaced, so that 
   there is no point at which another process attempting to access 
   newpath will find it missing.  However, there will probably be a 
   window in which both oldpath and newpath refer to the file being 
   renamed.

> I might implement that, as well.  It doesn`t really matter however, 
> as in practice the structures than contain thermometer data don`t get 
> altered if no valid data is found, so the lack of a proper file, ex 
> of causing a crash, now simply means the (unused in this program) 
> name data gets erased.  For a few seconds.  It simply misses a 
> reading and uses last times data for everything else.  Mostly the 
> temperature.

Yes, your temperature monitoring was unaffected.  But if the race was 
sometimes triggering the pointer double-free that your loop previously 
had, then the lack of atomicity was at least one trigger for the 
intermittent crash.

So seems like two routes to fix:

1) remove the conditions that can cause a double-free to occur in the 
   code (seems like you`ve already done this from other posts)

2) use rename() to move newly written files into place for the reader, 
   so the reader never opens an empty file (exclusive of the writer 
   crashing before it wrote anything to the file).

For something that you`ll potentially want to `just run` for 
months/years on end without daily care and feeding, doing both is the 
better defense.
--- tin/2.6.1-20211226 ("Convalmore") (Linux/5.15.117 (x86_64))
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441