bug#30421: 25.3; desktop.el: Steal lock when no living "emacs" process owns it

[Eli Zaretskii]

> From: Pierre Neidhardt <ambrevar@gmail.com>
> Date: Sun, 11 Feb 2018 10:54:13 +0100
> 
> 
> By default, desktop-save-mode will not save (and will set
> desktop-dirname to nil) if a lock file exists with a PID in it.
> 
> It's problematic however when Emacs gets killed and does not release the
> lock.  Upon next start, desktop-save-mode will refuse to save because
> the lock exists, even though no process is using it.  In terms of user
> experience, it's pretty bad considering the error feedback is just one
> line in the *Messages* buffer (I almost never notice it when it happens)
> and the problem is persistent across reboots (the lock file will remain
> as long as the user does not remove it manually).

When this happens to me, the next time I start Emacs, I'm asked
whether to use the desktop file that appears to be locked, and if I
answer YES, desktop.el goes on to restore the session, no other
questions asked, and saves the desktop upon exit with no problems.
I'm confused as to why you see something different.  Could it be that
your activation of desktop-save-mode is somehow different from mine?

> Furthermore, isn't it strange to just check if there lock file contains
> a number and not actually check if it's an existing PID?

You are assuming that the locking process runs on the same machine,
but that is not guaranteed.  The directory where the desktop file
lives could be mounted via the network, I think.