bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pierre Neidhardt
Subject: bug#30421: 25.3; desktop.el: Steal lock when no living "emacs" process owns it
Date: Sun, 11 Feb 2018 17:08:10 +0100
User-agent: mu4e 1.0; emacs 25.3.1

Eli Zaretskii <eliz@gnu.org> writes:

>> 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?

I always run Emacs daemon.  And I think the following excerpt explains
it all:

        (defun desktop-read (&optional dirname)
        ...
        (or (null desktop-load-locked-desktop)
            (daemonp)
            (not (y-or-n-p (format "Warning: desktop file appears to be in use 
by PID %s.\n\
        Using it may cause conflicts.  Use it anyway? " owner))))

Not sure why (daemonp) is here.  Removing this line would solve the issue.

I just realized that `desktop-load-locked-desktop' is also a solution to
my problem.

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

You mean in case two Emacs instances on two separate machines share the
same location for `desktop-full-lock-name' over network?  I don't know,
is there such a use case?  I might not see the point.

--
Pierre Neidhardt

Troubles are like babies; they only grow by nursing.

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]