mirror of
https://git.openafs.org/openafs.git
synced 2025-01-18 15:00:12 +00:00
f951a9bf9b
Our openafs-client.service systemd unit currently has some unfortunate behaviors: - If someone runs 'systemctl stop openafs-client' and someone is using /afs, our umount will fail, and systemd will consider the openafs-client unit failed and deactivated. Trying to stop the unit again won't do anything, and trying to start the unit will fail because of our 'fs sysname' check. The client can then only be stopped by manually running umount/rmmod. - If our kernel module is already initialized (because afsd failed during startup, or someone 'umount'd /afs without unloading the kernel module), running 'systemctl start openafs-client' will try to start afsd with an already-initialized kernel module, which will either fail or cause errors/panics. To improve this situation, change our startup sequence to unload the kernel module if it's already loaded (and then load it again right afterwards). This should guarantee that we won't use an already-initialized kernel module when we run afsd. This also means we will fail during startup if the kernel module cannot be unloaded for any reason (for example, if the client is already running but the 'fs sysname' check somehow didn't detect this). Also change our 'fs sysname' check to return success if the client is already running, instead of failure. This means that after a failed 'stop', the user can run 'start' and then 'stop' again to try and stop the client. Just running 'stop' again still won't do anything, which is not ideal, but that's just how systemd works. Move our 'afsd -shutdown' and 'rmmod' steps into ExecStopPost, so they may get run in some additional corner cases for a partially-initialized service. Add --verbose to a few commands, to make it a little clearer what's happening in what order in systemd logs. If we cannot unload the openafs kernel module when stopping (because, for example, we couldn't 'umount /afs' because it was in use), log some information about how the user can actually get the client stopped. Change-Id: I78463160a1835137efaeeb0f27bb19c78171e9da Reviewed-on: https://gerrit.openafs.org/15647 Tested-by: BuildBot <buildbot@rampaginggeek.com> Reviewed-by: Cheyenne Wills <cwills@sinenomine.net> Reviewed-by: Michael Meffie <mmeffie@sinenomine.net> Reviewed-by: Andrew Deason <adeason@sinenomine.net> |
||
|---|---|---|
| build-tools | ||
| doc | ||
| src | ||
| tests | ||
| .gitignore | ||
| .gitreview | ||
| .mailmap | ||
| .splintrc | ||
| acinclude.m4 | ||
| CODING | ||
| configure-libafs.ac | ||
| configure.ac | ||
| CONTRIBUTING | ||
| INSTALL | ||
| libafsdep | ||
| LICENSE | ||
| Makefile-libafs.in | ||
| Makefile.in | ||
| NEWS | ||
| NTMakefile | ||
| README | ||
| README-WINDOWS | ||
| regen.sh | ||
AFS is a distributed file system that enables users to share and access all of the files stored in a network of computers as easily as they access the files stored on their local machines. The file system is called distributed for this exact reason: files can reside on many different machines, but are available to users on every machine. OpenAFS 1.0 was originally released by IBM under the terms of the IBM Public License 1.0 (IPL10). For details on IPL10 see the LICENSE file in this directory. The current OpenAFS distribution is licensed under a combination of the IPL10 and many other licenses as granted by the relevant copyright holders. The LICENSE file in this directory contains more details, thought it is not a comprehensive statement. See INSTALL for information about building and installing OpenAFS on various platforms. See CODING for developer information and guidelines. See NEWS for recent changes to OpenAFS.