Messages in this thread | | | Date | Tue, 1 Jun 1999 05:03:17 +0100 (GMT) | From | Riley Williams <> | Subject | Re: 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/
| |