The following commit has been merged in the openafs-stable-1_8_x branch:
commit 533f4241cc1617e8081236609399e2e41a8048a6
Author: Cheyenne Wills <cwi...@sinenomine.net>
Date: Mon Jan 22 15:06:56 2024 -0700
RedHat: Use KillMode=process for systemd client
Our openafs-client.service systemd unit file contains a deprecated
option, KillMode=none. Using this option results in the following
message with systemd version 246 or later:
/lib/systemd/system/openafs-client.service:22: Unit configured to
use KillMode=none. This is unsafe, as it disables systemd's
process lifecycle management for the service. Please update your
service to use a safer KillMode=, such as 'mixed' or
'control-group'. Support for KillMode=none is deprecated and
will eventually be removed.
Without this option, if someone runs 'systemctl stop openafs-client'
and the client fails to shutdown (e.g., because files are accessing
/afs), systemd will try to kill all of our afsd processes. Our afsd
processes usually either cannot be killed, or will cause unstable
behavior if they are killed (because e.g. AFSDB requests cannot be
fulfilled).
If systemd cannot kill all of our afsd processes, it will wait for a
timeout before reporting an error. By default, it waits 90 seconds
before sending SIGTERMs, and another 90 seconds before sending
SIGKILLs. This means that by default, if someone is using /afs,
'systemctl stop openafs-client' will hang for 3 minutes (!), even
though we know immediately that we cannot stop the client.
One way to avoid this is using KillMode=none, which skips killing our
processes and waiting for any timeouts. To avoid using a deprecated
option, switch to using KillMode=process.
With KillMode=process, after a failed 'stop', systemd will only try to
kill the 'main' pid run by ExecStart. The 'main' pid is detected by
systemd either automatically by some heuristic (with
GuessMainPID=yes), or by a pid file (when PIDFile= is set). If we
disable GuessMainPID and don't set PIDFile, systemd will not try to
terminate any of our processes on shutdown.
systemd will still try to kill our other remaining processes using
SIGKILL, but we can disable that with SendSIGKILL=no. To be safe, also
specify KillSignal=SIGCONT to make sure systemd doesn't actually
forcibly kill any of our afsd processes.
None of this matters during a successful client shutdown, since then
all of our afsd processes go away after a successful unmount, and
there's nothing to cleanup.
Our behavior during a failed 'stop' is still not ideal. After a failed
'stop', systemd will flag the service as "failed (Result: exit-code)".
This is similar to a service that is stopped successfully
(deactivated), and running 'systemctl stop' on it again does nothing.
Running 'systemctl start openafs-client' will try to start the service
again, but this will fail because of the ExecStartPre check that runs
'fs sysname', and the service will still be considered
failed/deactivated. The only way to fix the situation is for an
administrator to run the shutdown sequence manually, unmounting /afs
and removing the kernel module themselves, and then starting the
client again.
That behavior is unfortunate, but seems difficult or impossible to
avoid with a single systemd service.
Reviewed-on: https://gerrit.openafs.org/15613
Reviewed-by: Andrew Deason <adea...@sinenomine.net>
Tested-by: BuildBot <build...@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmef...@sinenomine.net>
(cherry picked from commit df3b8129ce9ce3c211e3cfa2033ac72e008f3895)
Change-Id: Ifbdcad1e39ce77a63121972d4561424e243ab4d1
Reviewed-on: https://gerrit.openafs.org/16104
Reviewed-by: Andrew Deason <adea...@sinenomine.net>
Reviewed-by: Mark Vitale <mvit...@sinenomine.net>
Reviewed-by: Michael Meffie <mmef...@sinenomine.net>
Tested-by: BuildBot <build...@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <ka...@mit.edu>
src/packaging/RedHat/openafs-client.service | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--
OpenAFS Master Repository
_______________________________________________
OpenAFS-cvs mailing list
OpenAFS-cvs@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-cvs
