GNU bug report logs - #63058
28.2; Emacs is terminated by Windows when logging off even if modified buffers are open

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63058 in the body.
You can then email your comments to 63058 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Harald Sanftmann <haraldsa <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.2; Emacs is terminated by Windows when logging off even if
 modified buffers are open
Date: Mon, 24 Apr 2023 17:48:59 +0200

Hi everybody,


From time to time it happens that I have not closed Emacs before
logging out. Windows just terminates the process even if modified
buffers are open.

I searched for a solution and learned how Windows is telling
applications to prepare for the user logging off / Windows is shutting
down:
https://www.howtogeek.com/396277/what-exactly-happens-when-you-shut-down-or-sign-out-of-windows/

WM_QUERYENDSESSION and WM_ENDSESSION are the sent signals, if the
application does not respond it will be terminated after 5 seconds.

Then I found some code which could be the Emacs implementation:


https://github.com/emacs-mirror/emacs/blob/master/src/w32fns.c

      switch (msg)
        {
        case WM_ERASEBKGND:
           ...
        case WM_ENDSESSION:
        my_post_msg (&wmsg, hwnd, msg, wParam, lParam);
        /* Allow time for Emacs to attempt an orderly shutdown.  If we
           return, the process will be terminated immediately.  FIXME:
           1000 seconds is too long to sleep if the shutdown attempt
           fails (see bug#25875).  But if it fails, we want to find out
           about it, so let's leave 1000 for now.  */
        sleep (1000);
        FALLTHROUGH;

Seems like Emacs does not respond but sleeps for 1000 s. This will
probably not cut it.

Would be great to have a proper handling.

Thanks & Reards,
Harald


In GNU Emacs 28.2 (build 2, x86_64-w64-mingw32)
 of 2022-09-13 built on AVALON
Windowing system distributor 'Microsoft Corp.', version 10.0.22621
System Description: Microsoft Windows 10 Pro (v10.0.2009.22621.1555)

Configured using:
 'configure --with-modules --without-dbus --with-native-compilation
 --without-compress-install CFLAGS=-O2'

Configured features:
ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
XPM ZLIB

(NATIVE_COMP present but libgccjit not available)

Important settings:
  value of $LANG: DEU
  locale-coding-system: cp1252

Major mode: Org

Message #8 received at 63058 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Harald Sanftmann <haraldsa <at> web.de>
Cc: 63058 <at> debbugs.gnu.org
Subject: Re: bug#63058: 28.2;
 Emacs is terminated by Windows when logging off even if modified
 buffers are open
Date: Tue, 25 Apr 2023 09:21:05 +0300

> Date: Mon, 24 Apr 2023 17:48:59 +0200
> From: Harald Sanftmann <haraldsa <at> web.de>
> 
>  From time to time it happens that I have not closed Emacs before
> logging out. Windows just terminates the process even if modified
> buffers are open.

That's the expected behavior in that case.  Emacs should auto-save
when the OS tells Emacs it is shutting down, so you have auto-save
files to restore the session later, when the system is restarted.

> I searched for a solution and learned how Windows is telling
> applications to prepare for the user logging off / Windows is shutting
> down:
> https://www.howtogeek.com/396277/what-exactly-happens-when-you-shut-down-or-sign-out-of-windows/
> 
> WM_QUERYENDSESSION and WM_ENDSESSION are the sent signals, if the
> application does not respond it will be terminated after 5 seconds.
> 
> Then I found some code which could be the Emacs implementation:
> 
> 
> https://github.com/emacs-mirror/emacs/blob/master/src/w32fns.c
> 
>        switch (msg)
>          {
>          case WM_ERASEBKGND:
>             ...
>          case WM_ENDSESSION:
>          my_post_msg (&wmsg, hwnd, msg, wParam, lParam);
>          /* Allow time for Emacs to attempt an orderly shutdown.  If we
>             return, the process will be terminated immediately.  FIXME:
>             1000 seconds is too long to sleep if the shutdown attempt
>             fails (see bug#25875).  But if it fails, we want to find out
>             about it, so let's leave 1000 for now.  */
>          sleep (1000);
>          FALLTHROUGH;
> 
> Seems like Emacs does not respond but sleeps for 1000 s. This will
> probably not cut it.

This is not what happens; you saw only the first part of how Emacs on
Windows handles this situation, in the input thread.  What actually
happens is that before the input thread starts sleeping above, it
posts the WM_ENDSESSION message, via the my_post_msg call, to the main
thread, where we have this:

	case WM_ENDSESSION:
	  inev.kind = END_SESSION_EVENT;
	  break;

So this event gets inserted into the Emacs input event queue, and when
it is processed, we do:

    case END_SESSION_EVENT:
      /* Make an event (end-session).  */
      return list1 (Qend_session);

The above produces a Lisp event 'end-session', for which we have a
default binding:

  initial_define_lispy_key (Vspecial_event_map, "end-session",
			    "kill-emacs");

IOW, this event by default calls the command kill-emacs.  And that
command auto-saves any modified buffers that visit files, then shuts
down Emacs.

> Would be great to have a proper handling.

What is a proper handling in this case? delay the shutdown
indefinitely? that'd be even less proper, IMO.

See also bug#23483 (which led to the existing implementation) and
specifically these messages there:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23483#37
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23483#40
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23483#43
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23483#46

You could, if you like, bind the end-session event to a different
command, perhaps that will suit your usage better.  But be very
careful when you do this, because invoking commands that require user
interaction will not work in this case: the Emacs' input thread, which
handles all kinds of inputs, is sleeping, so the user cannot interact
with Emacs.

Message #11 received at 63058 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: haraldsa <at> web.de
Cc: 63058 <at> debbugs.gnu.org
Subject: Re: bug#63058: 28.2;
 Emacs is terminated by Windows when logging off even if modified
 buffers are open
Date: Fri, 05 May 2023 08:59:13 +0300

tags 63058 notabug
close 63058
thanks

> Cc: 63058 <at> debbugs.gnu.org
> Date: Tue, 25 Apr 2023 09:21:05 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> This is not what happens; you saw only the first part of how Emacs on
> Windows handles this situation, in the input thread.  What actually
> happens is that before the input thread starts sleeping above, it
> posts the WM_ENDSESSION message, via the my_post_msg call, to the main
> thread, where we have this:
> 
> 	case WM_ENDSESSION:
> 	  inev.kind = END_SESSION_EVENT;
> 	  break;
> 
> So this event gets inserted into the Emacs input event queue, and when
> it is processed, we do:
> 
>     case END_SESSION_EVENT:
>       /* Make an event (end-session).  */
>       return list1 (Qend_session);
> 
> The above produces a Lisp event 'end-session', for which we have a
> default binding:
> 
>   initial_define_lispy_key (Vspecial_event_map, "end-session",
> 			    "kill-emacs");
> 
> IOW, this event by default calls the command kill-emacs.  And that
> command auto-saves any modified buffers that visit files, then shuts
> down Emacs.
> 
> > Would be great to have a proper handling.
> 
> What is a proper handling in this case? delay the shutdown
> indefinitely? that'd be even less proper, IMO.
> 
> See also bug#23483 (which led to the existing implementation) and
> specifically these messages there:
> 
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23483#37
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23483#40
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23483#43
>   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23483#46
> 
> You could, if you like, bind the end-session event to a different
> command, perhaps that will suit your usage better.  But be very
> careful when you do this, because invoking commands that require user
> interaction will not work in this case: the Emacs' input thread, which
> handles all kinds of inputs, is sleeping, so the user cannot interact
> with Emacs.

No further comments, so I'm now closing this issue, as I see no bug
here: Emacs is behaving as intended.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.