Package: emacs-bin-common
Version: 1:27.1+1-3.1
Severity: normal
File: emacs.service
There are a few reports of this online, and I've personnally
experienced it myself. Here's a good example:
https://www.reddit.com/r/emacs/comments/do67z3/emacsservice_will_delay_2_mins_before/
In the above, Emacs hangs the shutdown sequence for 2 minutes, waiting
for the user to say "yes" to:
Buffer recentf<3> modified; kill anyway?
which, I'm sure you will agree, is kind of silly. It's nice that
systemd is waiting for the user to answer, but it's not nice that (a)
it's hanging the shutdown process, and especially (b) that it ends up
killing it with SIGKILL in the end anyways, losing those unsaved
buffers.
A workaround proposed in the above thread is to use this ExecStop:
ExecStop=/usr/bin/emacsclient --eval "(save-buffers-kill-terminal t)"
But I've found that it fails here to, as I have a `confirm-kill-emacs`
variable (set to `y-or-n-p`) which still prompts for exit. So it seems
that needs to be overriden as well. I've been experimenting with:
ExecStop=/usr/bin/emacsclient --eval "(let ((confirm-kill-emacs nil)) (save-buffers-kill-terminal t))"
... but so far, Emacs still takes forever to stop. It might be that
I'm failing to use the override directory, however. Who knows...
I think a reproducer for this is to have this in your .emacs:
(setq confirm-kill-emacs 'y-or-n-p)
Then start emacs from systemd:
systemctl start emacs
And then try to stop it:
systemctl stop emacs
Normally, this should be very quick, but it will take a while to stop,
I think the timeout is at two minutes. Then you will see this in
status:
sep 13 12:49:27 curie systemd[168846]: emacs.service: State 'stop-sigterm' timed out. Killing.
sep 13 12:49:27 curie systemd[168846]: emacs.service: Killing process 185133 (emacs) with signal SIGKILL.
sep 13 12:49:27 curie systemd[168846]: emacs.service: Main process exited, code=killed, status=9/KILL
sep 13 12:49:27 curie systemd[168846]: emacs.service: Failed with result 'timeout'.
A.