lkml.org 
[lkml]   [1999]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: How can Emacs get a unique ID per Linux reboot?
Hi Paul.

> I'm trying to help RMS fix a problem with Linux and recent test
> releases of GNU Emacs. When the user edits a file FOO, Emacs
> 20.3.10 creates a symbolic link from .#FOO to
> USER@HOSTNAME:PID:BOOTID, where BOOTID is a unique identifier
> for this reboot of the kernel. This symlink lets Emacs
> determine whether someone else is editing this file. The
> symlink is stale if BOOTID does not correspond to last time that
> the kernel was rebooted. (Emacs doesn't rely on lockf or its
> relatives to create advisory locks on files; I believe that this
> is because they aren't portable and reliable enough with
> networked file systems.)

> For most operating systems, BOOTID is the timestamp of the last
> reboot. For example, if I edit FOO on Solaris 7, Emacs might
> create a symbolic link from .#FOO to
> eggert@shade.twinsun.com.18323:924306205, since
> shade.twinsun.com was last rebooted 924306205 seconds after
> 1970-01-01 00:00:00 UTC.

> Unfortunately, RMS and I haven't been able to discover a
> documented, guaranteed, and fast way to get a unique reboot ID
> for Linux.

> Linux's /proc/stat has a btime line which seems plausible, but
> unfortunately btime is calculated backwards by subtracting the
> uptime from the current time, which means that btime changes
> whenever you change the date. Using btime means that changing
> the date invalidates Emacs's advisory locks. (I think that this
> btime behavior is a bug; is it possible to fix it?)

> Solaris 7 and many other Unixes put a reboot record in
> /var/adm/utmp, but Linux's /var/run/utmp does not have a reboot
> record; it has only a run-level change record. Emacs can't use
> this, since it would mean that changing run levels would
> invalidate Emacs's advisory locks. (Perhaps Linux could add a
> reboot record to /var/run/utmp, for compatibility with other
> Unixes; this would solve Emacs's problem as well.)

> Another possibility is to scan through /var/log/wtmp looking for
> a reboot record (and if it isn't found, then scan through
> /var/log/wtmp.0, /var/log/wtmp.1.gz, etc.). This is slow, since
> wtmp might be very large. And it might not report a reboot
> time, since wtmp is rotated, which means that the reboot record
> might be too old to be in wtmp. This method is reliable: when
> it does report a boot time, the boot time is accurate. But it's
> too slow for Emacs.

> Is there a better way to solve this problem? We need a
> documented and guaranteed way to get a value that will never
> change except when the system is rebooted, and will not be the
> same for two reboots unless something really weird is done.

One possibility would be to calculate the equivalent of...

Q> #!/bin/bash
Q> echo $[`date +%s`-`tr ' ' . < /proc/uptime | cut -d . -f 1`]

...as, at least on my system, that returns a constant value.

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.497 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site