From: Pierre Neidhardt <ambrevar@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 30421@debbugs.gnu.org
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 [thread overview]
Message-ID: <87r2prpl05.fsf@gmail.com> (raw)
In-Reply-To: <83mv0f1q6t.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2271 bytes --]
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
next prev parent reply other threads:[~2018-02-11 16:08 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-11 9:54 bug#30421: 25.3; desktop.el: Steal lock when no living "emacs" process owns it Pierre Neidhardt
2018-02-11 15:50 ` Eli Zaretskii
2018-02-11 16:08 ` Pierre Neidhardt [this message]
2018-02-11 16:15 ` Noam Postavsky
2018-02-11 16:32 ` Eli Zaretskii
2018-02-11 16:57 ` Pierre Neidhardt
2018-02-11 17:18 ` Eli Zaretskii
2018-02-11 17:23 ` Pierre Neidhardt
2018-02-11 18:00 ` Eli Zaretskii
2018-02-11 18:41 ` Pierre Neidhardt
2018-02-11 18:54 ` Eli Zaretskii
2018-02-11 19:01 ` Pierre Neidhardt
2018-02-15 22:56 ` Pierre Neidhardt
2018-02-16 8:11 ` Eli Zaretskii
2018-02-16 22:58 ` Pierre Neidhardt
2018-02-17 7:43 ` Eli Zaretskii
2018-02-18 11:26 ` Pierre Neidhardt
2018-02-18 16:37 ` Eli Zaretskii
2018-02-24 10:39 ` Eli Zaretskii
2018-02-24 19:44 ` Pierre Neidhardt
2018-02-24 20:09 ` Eli Zaretskii
2018-03-03 11:33 ` Eli Zaretskii
2018-03-03 18:05 ` Pierre Neidhardt
2018-03-10 11:52 ` Eli Zaretskii
2018-03-19 11:06 ` Pierre Neidhardt
2018-03-19 12:47 ` Eli Zaretskii
2018-03-19 13:09 ` Pierre Neidhardt
2018-02-11 20:40 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r2prpl05.fsf@gmail.com \
--to=ambrevar@gmail.com \
--cc=30421@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).