Detect Linux Runlevel

[Tim Chase]

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
purposes.

http://pubs.opengroup.org/onlinepubs/009695399/functions/write.html#tag_03_866_08

(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. ;-)

-tkc