Detect Linux Runlevel
python.list at tim.thechases.com
Tue Dec 6 20:00:43 EST 2016
On 2016-12-07 00:29, Marko Rauhamaa wrote:
> Tim Chase <python.list at tim.thechases.com>:
> > This works based on my poking at it in both Py2 and Py3:
> Great info, Tim.
> 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.
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. So
as long as the writer is writing a record at a time (or less) and not
issuing multiple writes to update disjoint parts of the record, I'm
pretty confident that atomicity won't be an issue for all intents and
(though according to my "man 2 write" on my Linux box, before Linux
3.14, it wasn't atomic according to specs)
> The library functions getutline(), pututline() etc lock the file
> internally (although that is not documented). You can see the
> (advisory record) locking in action by running the command
C API functions which don't appear to be exposed in stock Python. ;-)
> Another thing is that, as stated before, the runlevel business is
> legacy. It is still supported by systemd-update-utmp, but for how
> long is anybody's guess.
Much like Unix itself, if the OP chooses to shoot off his own feet
with them, my aim is to do it efficiently as requested. ;-)
More information about the Python-list