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