On Wednesday 10 August 2016, Martin Wilck wrote:
On Wed, 2016-08-10 at 12:25 +0200, Ruediger Meier wrote:
On Wednesday 10 August 2016, Andrei Borzenkov wrote:
From logind creating session scope.
src/login/logind-dbus.c:manager_start_scope()
/* Make sure that the session shells are terminated with * SIGHUP since bash and friends tend to ignore SIGTERM */ r = sd_bus_message_append(m, "(sv)", "SendSIGHUP", "b", true); if (r < 0) return r;
This makes no sense to me, processes which want to ignore SIGTERM get what they deserve later: SIGKILL (after a ridiculous long timeout, default 90s). BTW other processes may reload their configs on SIGHUP ... while shutdown.
SIGHUP is sent immediately after SIGTERM,
Actually I get 3 signals within the same millisecond.
to avoid the long timeout you complain about.
It could also try all other kind of signals ... to increase the chance that the process will run into SIG_DFL ...
(Btw the timeout may be just long enough for some services that need to shut down cleanly - the 90s default timeout applies to any service, not just user sessions).
The shell sends SIGHUP to children at exit, so most processes that run interactively from a shell will be able to deal with that.
Processes that re-read configuration at SIGHUP will normally be daemons started by their on unit files.
What is normal? Here at my office most users are running all kinds of daemons. None of them ever heard something about "unit files". We also have a few gnome or kde users. They have even many daemons running automatically after login.
Moreover why it sends SIGHUP two times plus SIGTERM one time? Just to check if any program has a rock-solid signal handler implemented?
As far as I can tell it is not configurable. You may consider using systemd-run to start those processes outside of normal session scope.
This means I have to start basically _any_ process with systemd-run? Should I try to set my login shells to "systemd-run --user /bin/bash"
Why that? /bin/bash is supposed to be sent a SIGHUP, that's the whole point.
BTW in future systemd-logind seems to be even more agressive: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 Hope that openSUSE does not use this insane default.
KillUserProcesses is configurable in logind.conf. But traditionally, it's normal behaviour that background processes are killed when you log out.
No, my ssh-agent and many other progs have always run forever after starting them once. bash even seem to automatically "nohup" child processes (may depend on the used terminal). zsh only send SIGHUP to background childs if stdin or stdout is connected to the terminal. systemd again changes known behavior.
If you don't want that, use nohup or at - this allows you to be specific about the processes you don't want to be killed. That's a good thing IMO, otherwise the system is likely to be burdened with forgotten/abandoned user processes.
You have not understood that in systemd-230 especially nohup, screen and friends will be killed by default too ... the traditional way how to run background processes is not the default anymore ... cu, Rudi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org