# Entries in this file show the compile time defaults. Local configuration[...]
# should be created by either modifying this file (or a copy of it placed in # /etc/ if the original file is shipped in /usr/), or by creating "drop-ins" in
# the /etc/systemd/logind.conf.d/ directory. The latter is generally
# recommended. Defaults can be restored by simply deleting the main
# configuration file and all drop-ins located in /etc/.
#
# Use 'systemd-analyze cat-config systemd/logind.conf' to display the full config.
#
# See logind.conf(5) for details.
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
Found this as well which has more information about how systemd might
shut down your user slice
https://serverfault.com/questions/1137788/how-to-debug-systemd-shutdown-failing-to-gracefully-shutdown
which lnks to https://www.freedesktop.org/software/systemd/man/latest/systemd.kill.html#KillMode=
if you've verified your process gets a KILL signal and no TERM before
hand, and the various unit / sessions settings are configured to send
TERM before KILL, I guess that would be a systemd bug. but I guess,
more likely than a bug, would be that the (potentially complicated) interaction between how systemd manages processes and how it can be configured is not configured to send a TERM first.
since there doesn't seem to be a way to turn on debugging so systemd
tells you what it's doing, you may have to either code up a patch to
add more logging to systemd, or manually check the (again, potentially complicated) settings to see how those settings are telling systemd to
kill your user session / slice. that of course also requires
understanding what a session or slice even is, which I don't claim to
know.
not trying to be unhelpful here -- I was looking into this cuz I
wanted to learn more about systemd, and the answer seems to be "it's potentially quite complicated"
On Fri, Mar 20, 2026 at 9:07?AM Daniel Sterling
<sterling.daniel@gmail.com> wrote:
from https://github.com/systemd/systemd/blob/main/src/shutdown/shutdown.c
it looks like systemd does indeed try to term then kill all processes
log_info("Sending SIGTERM to remaining processes...");
broadcast_signal(SIGTERM, true, true, arg_timeout);
log_info("Sending SIGKILL to remaining processes...");
broadcast_signal(SIGKILL, true, false, arg_timeout);
do you see those entries in your logs?
On Fri, Mar 20, 2026 at 8:33?AM alain williams <addw@phcomp.co.uk> wrote:
I find that when I do a reboot or poweroff (from command line) running
processes are not being sent SIGTERM. The one that really annoys me is a text
editor not receiving it and thus me losing work.
The systemd documentation says that it should be sent; good old init used to do
this.
Is the documentation wrong or do I need to tweak some config somewhere ? >> >
I am running Debian 13 with the mate desktop. MATE Terminal provides the >> > terminal emulation. The editor is my own version of microemacs (which does >> > handle SIGTERM correctly).
The GUI (mate, etc) is actually irrelevant - the same thing happens to the >> > editor being run on a console.
TIA
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h>
The text editor is the OP's version (whatever that means) of microemacs (whatever that is); it seems conceivable that the bug could be in the editor, rather than in systemd.
On Sun, Mar 22, 2026 at 03:05:48PM -0000, CGS wrote:
The text editor is the OP's version (whatever that means) of microemacs
(whatever that is); it seems conceivable that the bug could be in the editor,
rather than in systemd.
No - I said that it handles SIGTERM correctly - I tested it before making this report.
On 2026-03-22, alain williams <addw@phcomp.co.uk> wrote:
On Sun, Mar 22, 2026 at 03:05:48PM -0000, CGS wrote:
The text editor is the OP's version (whatever that means) of microemacs
(whatever that is); it seems conceivable that the bug could be in the editor,
rather than in systemd.
No - I said that it handles SIGTERM correctly - I tested it before making this report.
Why would you reboot or poweroff without saving your work first?
Makes no sense to me.
On 2026-03-22, alain williams <addw@phcomp.co.uk> wrote:Why not? If the software does its thing, it all should go well.
On Sun, Mar 22, 2026 at 03:05:48PM -0000, CGS wrote:
The text editor is the OP's version (whatever that means) of microemacs
(whatever that is); it seems conceivable that the bug could be in the editor,
rather than in systemd.
No - I said that it handles SIGTERM correctly - I tested it before making this report.
Why would you reboot or poweroff without saving your work first?
On Sun, Mar 22, 2026 at 03:44:15PM -0000, CGS wrote:
On 2026-03-22, alain williams <addw@phcomp.co.uk> wrote:
On Sun, Mar 22, 2026 at 03:05:48PM -0000, CGS wrote:
The text editor is the OP's version (whatever that means) of microemacs >> >> (whatever that is); it seems conceivable that the bug could be in the editor,
rather than in systemd.
No - I said that it handles SIGTERM correctly - I tested it before making this report.
Why would you reboot or poweroff without saving your work first?
Makes no sense to me.
I have a hardware problem (graphics card occasionally crashes, I shall get a new one next week). This is what made me aware of the problem. I can ssh into the machine and poweroff (reboot is not enough, power cycle needed) - which is
what I did. I now send instances of the editor SIGTERM before typing poweroff -
thus it saves modified buffers.
I have a hardware problem (graphics card occasionally crashes, I shall get a
new one next week). This is what made me aware of the problem. I can ssh into
the machine and poweroff (reboot is not enough, power cycle needed) - which is
what I did. I now send instances of the editor SIGTERM before typing poweroff -
thus it saves modified buffers.
Right. I think the crashed system isn't performing a canonical poweroff.
Try powering off the machine when the system isn't crashed; this will demonstrate whether there's a bug or not.
Why would you reboot or poweroff without saving your work first?
Why not? If the software does its thing, it all should go well.
On Sun, Mar 22, 2026 at 04:41:24PM -0000, CGS wrote:
I have a hardware problem (graphics card occasionally crashes, I shall get a
new one next week). This is what made me aware of the problem. I can ssh into
the machine and poweroff (reboot is not enough, power cycle needed) - which is
what I did. I now send instances of the editor SIGTERM before typing poweroff -
thus it saves modified buffers.
Right. I think the crashed system isn't performing a canonical poweroff.
Reboot does not do a power cycle.
The graphics card crashes (system log has messages complaining about it), sometimes crashes the system but generally not - thus I can ssh in.
Try powering off the machine when the system isn't crashed; this will
demonstrate whether there's a bug or not.
Tried that and I get the same problem (in a VM, but will work the same). Why did
you think that I did not try that ?
I find that when I do a reboot or poweroff (from command line) running processes are not being sent SIGTERM. The one that really annoys me is a text editor not receiving it and thus me losing work.
The systemd documentation says that it should be sent; good old init
used to do this.
Is the documentation wrong or do I need to tweak some config somewhere ?
I am running Debian 13 with the mate desktop. MATE Terminal provides the terminal emulation. The editor is my own version of microemacs (which does handle SIGTERM correctly).
The GUI (mate, etc) is actually irrelevant - the same thing happens to the editor being run on a console.
I find that when I do a reboot or poweroff (from command line) running
processes are not being sent SIGTERM. The one that really annoys me is a text
editor not receiving it and thus me losing work.
The systemd documentation says that it should be sent; good old init
used to do this.
Is the documentation wrong or do I need to tweak some config somewhere ?
I am running Debian 13 with the mate desktop. MATE Terminal provides the
terminal emulation. The editor is my own version of microemacs (which does >> handle SIGTERM correctly).
The GUI (mate, etc) is actually irrelevant - the same thing happens to the >> editor being run on a console.
I have no idea what's really going on, but I think there are two
possible explanations:
- Your editor process is sent *another* signal (e.g. because of the
disappearance of some other endpoint of one of its file descriptors)
that makes it die without saving-work, before systemd gets a chance to
send it a SIGTERM. [ If that's the case, the problem is in your editor
which should handle that other signal better. ]
- Maybe same as above but systemd wouldn't send a SIGTERM anyway.
- Your process is not sent any signal. I think that would qualify as
a bug in systemd.
- The filesystem is read-only when your process gets SIGTERM so it can't
save your work?
=== Stefan
I find that when I do a reboot or poweroff (from command line)
running processes are not being sent SIGTERM. The one that really
annoys me is a text editor not receiving it and thus me losing work.
The systemd documentation says that it should be sent; good old init
used to do this.
Is the documentation wrong or do I need to tweak some config
somewhere ?
I am running Debian 13 with the mate desktop. MATE Terminal
provides the terminal emulation. The editor is my own version of
microemacs (which does handle SIGTERM correctly).
The GUI (mate, etc) is actually irrelevant - the same thing happens
to the editor being run on a console.
I have no idea what's really going on, but I think there are two
possible explanations:
- Your editor process is sent *another* signal (e.g. because of the
disappearance of some other endpoint of one of its file descriptors)
that makes it die without saving-work, before systemd gets a chance
to send it a SIGTERM. [ If that's the case, the problem is in your
editor which should handle that other signal better. ]
- Maybe same as above but systemd wouldn't send a SIGTERM anyway.
- Your process is not sent any signal. I think that would qualify as
a bug in systemd.
- The filesystem is read-only when your process gets SIGTERM so it
can't save your work?
I have no idea what's really going on, but I think there are two
possible explanations:
I removed generation of all of these messages and the recovery file is generated. So it seems that when the system is shutting down any terminal output causes the program to be immediately terminated or possibly just suspended and then later terminated.
So: problem with systemd ? What do you think ?
I don't fully understand the situation, but if it is that:
1. All your processes receive a SIGTERM
2. Your editor writes a message about that to your terminal
3. Your terminal already exited because it got a SIGTERM
3. So your editor never manages to write its message and then doesn't
follow through with writing open buffers to recovery file
?then I would say that the bug is in the editor because writes to file descriptors aren't guaranteed to succeed or even to not block forever,
so should it really be blocking an emergency action on the success of
that?
If we were to argue that the bug is in systemd, what would be the
systemd fix to that situation?
But perhaps I have misunderstood.
I don't fully understand the situation, but if it is that:
1. All your processes receive a SIGTERM
2. Your editor writes a message about that to your terminal
3. Your terminal already exited because it got a SIGTERM
3. So your editor never manages to write its message and then doesn't
follow through with writing open buffers to recovery file
?then I would say that the bug is in the editor because writes to file descriptors aren't guaranteed to succeed or even to not block forever,
so should it really be blocking an emergency action on the success of
that?
If we were to argue that the bug is in systemd, what would be the
systemd fix to that situation?
If I recall correctly, it was reported that the issue also occurs if
the editor is running on a Linux virtual console (/dev/tty2 or whatever).
In that case, unless I'm *very* confused, I don't believe there is any process associated with the terminal, or at least no process that can
be terminated by a signal.
At that point, I would want to see an strace of the editor being
signalled, and see exactly what happens. This could be incredibly
tricky to arrange, though. The trace log would need to continue being written while the system is being torn down. I don't know whether
that's possible.
I removed generation of all of these messages and the recovery file is generated. So it seems that when the system is shutting down any terminal output causes the program to be immediately terminated or possibly just suspended and then later terminated.
On Mon, Mar 23, 2026 at 09:48:35AM -0400, Stefan Monnier wrote:any
I have no idea what's really going on, but I think there are two
possible explanations:
I have found the cause of the problem. When my editor receives a signal (
catchable signal) it produces some messages (signal xx received; command trace; ...) and then saves modified buffers (to recovery file) and then says
goodbye. The what-is-happening messages are first in case saving bufferscauses
another signal.als.
I removed generation of all of these messages and the recovery file is generated. So it seems that when the system is shutting down any terminal output causes the program to be immediately terminated or possibly just suspended and then later terminated.
The solution, for me, is simple: do not generate nice 'error: this is happening' messages when a SIGTERM is received, but do so with other sign
The most common is SIGHUP when a network error kills a ssh session (thisworks
as expected).s
This is, IMHO, unexpected behaviour. In a shutdown situation the messages should be accepted and: output or ignored/thrown-away depending on what i
possible. I suspect that many programs will say something, a quick searchshows
an example of this:ding-controlled-manner
https://www.ibm.com/support/pages/how-applications-can-detect-when-job-en
So: problem with systemd ? What do you think ?
You have to be careful of what you do in a signal handler. If the
editor is trying to log messages to a log file like, "Received SIGTERM
on 03/23/2026 22:00:00", then things could get very tricky. That's
because any system call made must be AS-Safe a/k/a Asynchronous Signal
Safe. If the call is not AS-Safe, then that is Undefined Behavior
(UB) and you should expect nasal demons.
I removed generation of all of these messages and the recovery file is generated. So it seems that when the system is shutting down any terminal output causes the program to be immediately terminated or possibly just suspended and then later terminated.
Or maybe the writing of the error message causes reception of
another signal? Or it just blocks?
Where is this writing taking place? From the signal handler itself?
=== Stefan
On Mon, Mar 23, 2026 at 11:38:17PM -0400, Stefan Monnier wrote:SIGHUP or SIGPIPE might be candidates, when disappearing I/O is involved. Cheers
I removed generation of all of these messages and the recovery file is generated. So it seems that when the system is shutting down any terminal output causes the program to be immediately terminated or possibly just suspended and then later terminated.
Or maybe the writing of the error message causes reception of
another signal? Or it just blocks?
I will investigate later today.
On Tue, Mar 24, 2026 at 12:01:23AM -0400, Jeffrey Walton wrote:
You have to be careful of what you do in a signal handler. If the
editor is trying to log messages to a log file like, "Received SIGTERM
on 03/23/2026 22:00:00", then things could get very tricky. That's
because any system call made must be AS-Safe a/k/a Asynchronous Signal Safe. If the call is not AS-Safe, then that is Undefined Behavior
(UB) and you should expect nasal demons.
I am well aware of that. The signal handler code is careful to not use
stdio -
so thus open()/close()/write(); things like localtime() not used.
It does use strsignal() & strerror() which I am a bit dubious about.
On Tue, Mar 24, 2026 at 12:01:23AM -0400, Jeffrey Walton wrote:
You have to be careful of what you do in a signal handler. If the
editor is trying to log messages to a log file like, "Received SIGTERM
on 03/23/2026 22:00:00", then things could get very tricky. That's
because any system call made must be AS-Safe a/k/a Asynchronous Signal Safe. If the call is not AS-Safe, then that is Undefined Behavior
(UB) and you should expect nasal demons.
I am well aware of that. The signal handler code is careful to not use
stdio -
so thus open()/close()/write(); things like localtime() not used.
It does use strsignal() & strerror() which I am a bit dubious about.
It does use sprintf() (%ld) which I think should be safe.
| Sysop: | Jacob Catayoc |
|---|---|
| Location: | Pasay City, Metro Manila, Philippines |
| Users: | 5 |
| Nodes: | 4 (0 / 4) |
| Uptime: | 493851:46:53 |
| Calls: | 146 |
| Files: | 547 |
| D/L today: |
6 files (97K bytes) |
| Messages: | 76,953 |