Detect Linux Runlevel

Tim Chase python.list at tim.thechases.com
Thu Dec 8 12:30:48 EST 2016


On 2016-12-07 07:30, Marko Rauhamaa wrote:
> Tim Chase <python.list at tim.thechases.com>:
> > On 2016-12-07 00:29, Marko Rauhamaa wrote:
> >> A word a warning: your code doesn't lock /var/run/utmp before
> >> access, which is a race condition. The file may be updated at any
> >> time, and ordinary file reads may yield corrupted records.
> >
> > Since the code is reading in record-sized blocks and never
> > writing, I'm not sure how much possibility there is for a race
> > condition. At worst, I imagine that it would result in reading
> > the old data which isn't a horrible condition.
> 
> If you read a full record at an offset, you might be right. However,
> your code uses Python's buffered I/O:
> 
>       with open(utmp_fname, "rb") as f:
>           while True:
>               bytes = f.read(XTMP_STRUCT_SIZE)
> 
> instead of os.open() and os.read().

Interesting.  I read up on os.open() and os.read() 
https://docs.python.org/2/library/os.html#os.read
but didn't notice anything there clarifying that it was unbuffered
compared to the __builtins__.open() and fp.read() functions.

Could you point me to resources where I can learn more about the
distinctions?

> > For under a certain block-size (PIPE_BUF, which I think used to be
> > the minimum POSIX requirement of 512b, but is now 4096b on Linux),
> > *nix operating systems were atomic in their reading and writing.
> 
> That particular guarantee is true for pipes and FIFOs only.

Ah, my error in misreading that as globally applicable.  Thanks for
ensuring accuracy.

-tkc




More information about the Python-list mailing list