On 2016-12-07 00:29, Marko Rauhamaa wrote: > Tim Chase <python.l...@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 -- https://mail.python.org/mailman/listinfo/python-list
