Your message dated Fri, 12 Aug 2016 16:48:50 -0300
with message-id
<caafdzj-awh90udzhwf_558qexbiob_gvkaamkg5grxzfxju...@mail.gmail.com>
and subject line Re: Bug#834164: systemd: Services are not killed after a
timeout or killed immediately after ExecStop
has caused the Debian Bug report #834164,
regarding systemd: Services are not killed after a timeout or killed
immediately after ExecStop
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
834164: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834164
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: systemd
Version: 215-17+deb8u4
Severity: normal
I am trying to set up a service shutdown sequence in a way that the
service is asked nicely to quit, and if it doesn't, then it's killed
after a timeout. Sounds very simple - this is very basic.
According to man systemd.service,
TimeoutStopSec=
Configures the time to wait for stop. If a service is asked to
stop, but does not terminate in the specified time, it will be
terminated forcibly via SIGTERM, and after another timeout of equal
duration with SIGKILL (see KillMode= in systemd.kill(5)).
However, with this setup:
ExecStop=<ask the service nicely>
KillMode=none
TimeoutStopSec=10s
the service is NEVER killed - even after 10s timeout.
Maybe I don't understand what's written in the manual? I just can't
believe such a basic thing could seriously be overlooked up until now...
I've also tried the same with KillMode=process (and without KillMode at
all - it defaults to control-group), hoping that maybe it will give my
service some time to shut down after ExecStop=, but it killed the
process immediately (and it went into "failed" mode for not stopping
quickly enough). Why do we have ExecStop= at all if the service is
killed immediately anyway?
This behaviour us the same in a newer version of systemd in Linux Mint
18, so it's an upstream bug. (Either that, or I really don't understand
something that simple.)
Here is a sample .service file that can be used safely to test this
behaviour.
= = = = = = =
test.service
= = = = = = =
[Unit]
Description=Test service
[Service]
ExecStart=/usr/bin/screen -h 1024 -dmS test ftp nonExistentServer
Type=forking
ExecStop=/usr/bin/screen -p 0 -S test -X eval 'stuff \"ServiceGoDie\"\015'
# Change the command to "bye" to actually let the "service" quit
# Otherwise it is supposed to fail to quit peacefully
# and be killed after 10s after "systemctl stop test"
KillMode=none
TimeoutStopSec=10s
[Install]
WantedBy=multi-user.target
= = = = = = =
-- Package-specific info:
-- System Information:
Debian Release: 8.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.1.18-aufs (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages systemd depends on:
ii acl 2.2.52-2
ii adduser 3.113+nmu3
ii initscripts 2.88dsf-59
ii libacl1 2.2.52-2
ii libaudit1 1:2.4-1+b1
ii libblkid1 2.25.2-6
ii libc6 2.19-18+deb8u4
ii libcap2 1:2.24-8
ii libcap2-bin 1:2.24-8
ii libcryptsetup4 2:1.6.6-5
ii libgcrypt20 1.6.3-2+deb8u1
ii libkmod2 18-3
ii liblzma5 5.1.1alpha+20120614-2+b3
ii libpam0g 1.1.8-3.1+deb8u1+b1
ii libselinux1 2.3-2
ii libsystemd0 215-17+deb8u4
ii mount 2.25.2-6
ii sysv-rc 2.88dsf-59
ii udev 215-17+deb8u4
ii util-linux 2.25.2-6
Versions of packages systemd recommends:
ii dbus 1.8.20-0+deb8u1
ii libpam-systemd 215-17+deb8u4
Versions of packages systemd suggests:
pn systemd-ui <none>
-- no debconf information
--
darkpenguin
--- End Message ---
--- Begin Message ---
On 12 August 2016 at 12:26, Dark Penguin <darkpeng...@yandex.ru> wrote:
> Package: systemd
> Version: 215-17+deb8u4
> Severity: normal
>
>
> I am trying to set up a service shutdown sequence in a way that the service
> is asked nicely to quit, and if it doesn't, then it's killed after a
> timeout. Sounds very simple - this is very basic.
>
> According to man systemd.service,
>
> TimeoutStopSec=
> Configures the time to wait for stop. If a service is asked to
> stop, but does not terminate in the specified time, it will be
> terminated forcibly via SIGTERM, and after another timeout of equal
> duration with SIGKILL (see KillMode= in systemd.kill(5)).
>
> However, with this setup:
>
> ExecStop=<ask the service nicely>
>From the manpage:
After the commands configured in this option are run, all
processes remaining for a service are terminated according
to the KillMode= setting
This means (and has been clarified in later versions) that ExecStop
must wait for the service to finish.
> KillMode=none
this means SIGKILL will never be sent, as documented in systemd.kill manpage.
> TimeoutStopSec=10s
This applies to the command running in ExecStop, not to the remaining
processes after ExecStop.
In short, you need to make your ExecStop wait for the process to exit.
The manpage in later versions is more explicit in this regard:
Note that it is usually not sufficient to specify a
command for this setting that only asks the service to
terminate (for example, by queuing some form of
termination signal for it), but does not wait for it to do
so. Since the remaining processes of the services are
killed using SIGKILL immediately after the command exited,
this would not result in a clean stop. The specified
command should hence be a synchronous operation, not an
asynchronous one.
I'm thus closing as not a bug.
--
Saludos,
Felipe Sateler
--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
