tests/rx/perf-t and tests/rx/simple-t contain an identical section of
perl code for checking the exit status of the relevant server process.
The spacing around some string concatenations are missing some spaces.
Add the missing spaces.
Thanks to sahilcdq@proton.me and cwills@sinenomine.net for pointing
these out.
Change-Id: Ieca3e6e5eabbd1c65c07edc33f1a884fc0fac248
Reviewed-on: https://gerrit.openafs.org/15848
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Sahil Siddiq <sahilcdq@proton.me>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Commit 004c797daa (tests: Introduce 'make check TESTS=test/name')
removed various $(TESTS) makefile variables from the tests/ directory,
so we can run 'make check TESTS=test/name' and not interfere with the
build.
Later, commit 236cb51b83 (rx: Cleanup and build src/rx/test) changed
src/rx/test to be built by default, but src/rx/test/Makefile.in uses a
variable called $(TESTS).
As a result, now building with 'make check TESTS=test/name' fails, for
example:
$ make check TESTS=rx/simple
[...]
cd src && cd rx/test && make all
make[1]: Entering directory `.../src/rx/test'
make[1]: *** No rule to make target `rx/simple', needed by `test'. Stop.
make[1]: Leaving directory `.../src/rx/test'
To avoid this, rename $(TESTS) to $(BINS), just like commit 004c797daa
did. Also rename the related $(TH_TESTS) to $(TH_BINS) for consistency.
Change-Id: I2cdd4545ee99eb4ed69e8f55341e0ba4dc34d5f3
Reviewed-on: https://gerrit.openafs.org/15847
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Add a test case to rx/simple-t to cover the scenario where the server
aborts the call. To cause an abort, send a message with simple-client
that is longer than MAX_SIZE.
Change-Id: I77a3c74352e7e0226666454ca0646f2419469ab8
Reviewed-on: https://gerrit.openafs.org/15844
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Sahil Siddiq <sahilcdq@proton.me>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: Michael Meffie <mmeffie@sinenomine.net>
This adds a new test, rx/simple, which runs a simple rx client against a
server process. It does not make use of rxgen-generated RPCs, but
instead runs as a single stream of data on an rx call.
The client creates a new connection to this service and sends a string.
The server performs a simple transformation (rot13) and returns the new
string back to the client.
This commit adds the simple-client and simple-server programs, as well
as the "simple-t" script test driver. These programs serve as a very
simple example of using Rx, as well as a basic functionality test.
Co-developed-by: Andrew Deason <adeason@sinenomine.net>
Change-Id: I78862ecb75a9bb3ccbfef049d11a95182c5e0278
Reviewed-on: https://gerrit.openafs.org/15780
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
afsd prints output to the stdio streams. Usually afsd is run by an init
script or systemd unit, so the output is not directed to the terminal
and the stdio streams are buffered.
When afsd forks child processes, the forked processes inherit the
buffered streams and this causes the output to be duplicated in the
child proceses. For example, when running afsd from systemd, the
journal contains duplicated output messages:
# systemctl start openafs-client
...
... systemd[1]: Starting openafs-client.service - OpenAFS Client Service...
... afsd[292192]: afsd: All AFS daemons started.
... afsd[292170]: afsd: All AFS daemons started.
... fedora systemd[1]: Started openafs-client.service - OpenAFS Client Service.
To avoid the duplicated messages, and to ensure output is captured in
the event of a crash, set the stdout and stderr streams to be unbuffered
using setvbuf() when the afsd process starts.
Thanks to Mark Vitale for diagnosing this issue and to Andrew Deason for
suggesting the use of setvbuf() to set the stream buffering.
Change-Id: I57faac38f6667d431557793ce06a11b7f390a414
Reviewed-on: https://gerrit.openafs.org/15829
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Benjamin Kaduk <kaduk@mit.edu>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
When systemd tries to stop openafs-client.service during system
shutdown, our 'umount /afs' will fail if someone else is accessing
/afs. The openafs-client.service unit is then marked as deactivated
(and failed), and the shutdown sequence proceeds.
After all services have been stopped, systemd-shutdown tries to kill
all remaining processes with SIGTERM and then SIGKILL, waiting
DefaultTimeoutStopSec seconds (default: 90) for them to die. If there
are unkillable processes running (for example, afsd), this results in
at least a 3-minute delay.
It's hard to make sure there are no processes accessing /afs during
the shutdown sequence, since that could include processes outside of
defined systemd units. So some processes may be shutting down in
parallel with openafs-client.service, and so it's a race whether there
are /afs-using processes when we try to umount /afs.
To avoid the most common cases of this, retry our umount during
openafs-client's ExecStop for $UMOUNT_TIMEOUT seconds (default: 30),
to give other /afs-using processes a chance to go away. Only do this
if the system is shutting down (according to 'systemctl
is-system-running'), so users don't see a long delay running
'systemctl stop openafs-client' during normal system operation.
Written in collaboration with cwills@sinenomine.net.
Change-Id: I5755dbf4cddf4204ed6836f9f4f21c00133fcb39
Reviewed-on: https://gerrit.openafs.org/15633
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
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>
Giving NULL as the second argument to realpath isn't supported by some
platforms, including Solaris 10. Pass an allocated buffer instead.
Change-Id: Iec1268906d6a032e1b38b120e54fa5d9c31102c6
Reviewed-on: https://gerrit.openafs.org/15438
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Convert all C files in src/tests to include afsconfig.h and
afs/param.h as the very first includes, like the rest of the tree
does.
Remove references to config.h and HAVE_CONFIG_H; we don't use those.
Change-Id: I07166de1b0c80bf11a91a0758b32fb77cdf779d8
Reviewed-on: https://gerrit.openafs.org/15437
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Since commit: "afscp: Link against opr/roken/hcrypto" (4eeed830fa) added
libroken to the list of libraries used for building in src/tests, the
copy of snprintf.c in src/tests is no longer needed.
Remove snprintf.c from src/tests and update Makefile.in to remove
references to snprintf.o and use the appropriate set of libraries for
the build targets.
Change-Id: I4e67f38d22a4f2e487ad51af752e55ab23a6a526
Reviewed-on: https://gerrit.openafs.org/15341
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
In order to simplify a future change, introduce a Makefile macro that
defines the common libs used.
Add COMMON_LIBS which will initially be set to just $(LIBS).
Replace $(LIBS) with $(COMMON_LIBS) through the rest of the file. Add
$(COMMON_LIBS) to the afscp target.
In addition, split the long lines containing the list of libraries.
There are no functional changes in this commit.
Change-Id: Iaf1ef92fdc7fa6ec4adc0582f714416255c1c972
Reviewed-on: https://gerrit.openafs.org/15396
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Move the logic in our Exec* commands in our openafs-client.service
unit file into a helper script: openafs-client-systemd-helper.sh. This
makes it easier to control our increasingly-complex startup/shutdown
checks (and makes them easier to read), and reduces the clutter in our
openafs-client.service unit file.
This commit does not intentionally change any of our startup/shutdown
behavior yet; this just moves the existing logic into a script.
Update openafs.spec.in to install the helper script.
Change-Id: Iccbb4f7b28b840ee0c38b2cc57d899a1bda8b3e2
Reviewed-on: https://gerrit.openafs.org/15634
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
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.
Change-Id: Ibed2971f72e4cde2cbeaeefc3ac14325ac8f84e1
Reviewed-on: https://gerrit.openafs.org/15613
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
The SRCDIR_PARENT shell variable is set to the configure process current
working directory. It is used during configure to set the top level
directory variables used in the build; TOP_OBJDIR, TOP_INCDIR,
TOP_LIBDIR. It is also used during configure to specify the path to
generated programs.
However, this variable is redundant with the TOP_OBJDIR variable and the
name can be confusing, since the top build directory is not the source
parent directory when doing out-of-tree (objdir) builds.
Remove the SRCDIR_PARENT variable and set the top directory variables
early in configure. Use TOP_OBJDIR to indicate the path to generated
tools.
Change-Id: Iaf1ce7707e73dd3c8fdf849c9767e8b84401d5a7
Reviewed-on: https://gerrit.openafs.org/15816
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Since the original IBM code import, vol_listLock and vol_sleep_cond have been defined and
initialized, but never used; remove them.
No functional change is incurred by this commit.
Change-Id: Id0e735de5495120035d7a77fd08ee16d33dae8ba
Reviewed-on: https://gerrit.openafs.org/15140
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Since the original IBM code import, h_CheckHosts has zeroed 'zerofid'
but it is not referenced by any other code.
Remove the vestigial code.
No functional change is incurred by this commit.
Change-Id: I56ff2977bd210f2a37abf0b25f5e3aba2da19d85
Reviewed-on: https://gerrit.openafs.org/15101
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
When running afsd with the -memcache option, afsd_run will skip certain
AFSOP_* syscalls that are not needed for a memory cache, e.g.
AFSOP_CACHEINFO and AFSOP_VOLUMINFO. However, afsd -debug output still
misleadingly mentions these syscalls, as if they were about to be
invoked.
For AFSOP_CACHEINFO, this has been true since the original IBM code
import. For AFS_VOLUMEINFO, this was introduced with commit
1307b89188 memcache-no-volitems-20050113.
In order to avoid misleading debug output when running -memcache, move
the afsd_debug() calls under their respective AFSCALL_INIT_MEMCACHE
conditional clauses.
Change-Id: Id13b5fc7c39ccc0836204ecf213f0fe68f666889
Reviewed-on: https://gerrit.openafs.org/15566
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
The DEST variable depends on the sysname, so move the assignment of the
DEST variable to the end of the OPENAFS_SYSNAME macro which is where the
sysname value is determined.
Also fix the test for an empty DEST variable, which put the dummy 'x'
after the variable, not before, to guard against values that start with
a dash.
Change-Id: Iaf8deefc685a6c9b9897d83b25b8919792847796
Reviewed-on: https://gerrit.openafs.org/15821
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
If we are compiled without kerberos support, afscp_util.c generates a
warning, breaking the build when built with --enable-checking:
CC .../src/libafscp/afscp_util.o
.../src/libafscp/afscp_util.c:152:1: error: '_GetLocalSecurityObject' defined but not used [-Werror=unused-function]
To avoid this, don't define _GetLocalSecurityObject if we don't have
HAVE_KERBEROS.
Change-Id: I2515402e19c6c44ad70de6e6ab16c39d61334ab4
Reviewed-on: https://gerrit.openafs.org/15818
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
The function afs_InitCacheFile can return an error under two
conditions: if the number of calls exceeds the number of cache files
specified during cacheinit, and if there is an error while performing
the lookup for the cache filename. In both cases, there there is
nothing logged to assist in diagnosing the problem.
Add diagnostic warnings for the above two conditions with information
related to the error condition.
Change-Id: I887c8b8ec5840c0f1947b6153710b2dba26ab21c
Reviewed-on: https://gerrit.openafs.org/15570
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Our opr/softsig-t tests run softsig-helper to generate SIGSEGV and
SIGBUS signals (among other things), which may generate core files (if
'ulimit -c' is nonzero). The core files are useless, since we expect
those signals to be generated.
Usually the core files are generated in the build tree (where we run the
tests from), which is a minor annoyance. But some systems may be
configured to store core files in a central location (e.g.
/var/lib/systemd/coredump), which starts to build up over time after
many builds.
To avoid this, prevent core files from being generated in softsig-helper
for the SIGSEGV and SIGBUS cases by calling setrlimit().
Change-Id: Ice71e79009cf2b44d4cbe32233d3a7ee12e08d2d
Reviewed-on: https://gerrit.openafs.org/15795
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Commit 09aba81c50 (Cast LWP event functions to void pointer) fixed a
compiler warning when building binaries with LWP threaded, but did so in
a way that appeased the compiler but did not address the underlying
undefined behavior.
The ISO C standard states "a pointer to any object type may be converted
to a pointer to void and back again; the result shall compare equal to
the original pointer", but since a function is not defined as an object,
the conversion of function pointer to a void pointer is undefined.
Fix this by creating dummy integer globals to be used as the event ids
for the few places function pointers are used for event ids. The values
of the dummy variables are set but are never read.
Change-Id: I00084b882fe62cb0a82963ef45c390e5082c6fab
Reviewed-on: https://gerrit.openafs.org/15794
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
The merge-pod script is our simple custom preprocessor for man-page pod
files. The merge-pod script expects one or more arguments to specify the
input files and generates the output files in the same directory as the
input files. Unfortunately, this precludes us from using merge-pod to
do out-of-tree builds (a.k.a. objdir builds) which generate man-pages,
since the output files are written to the source directory.
Change merge-pod so when no input files are specified, merge-pod will
scan the man-page pod<n> directories for *.in files, and put the pod
output files in pod<n> directories in the current working directory.
With this change, merge-pod remains compatible with the old method,
which is still in use by the NT makefile and the regen.sh script, but
provides support for a future commit to invoke merge-pod from the
man-pages Makefile.
Change-Id: I36b5b851cd1a09d050cf21c65ab3ae160a5c15cb
Reviewed-on: https://gerrit.openafs.org/15788
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Errors from GetCell() are reported a bit oddly in its three callers:
- In WhichCellCmd() (and GetFidCmd() before change
Idd4727304061e1ec4eeddd98bd9eaab5de96e2b6), we print an odd "no such
cell" error for ENOENT, and a more normal message for all other
errors.
- In BadName() (and GetFidCmd() after change
Idd4727304061e1ec4eeddd98bd9eaab5de96e2b6), we don't print an error
at all, sometimes making it not obvious that an error has occurred.
(BadName() is called from 'fs cleanacl'.)
The ENOENT message can be confusing to users, since ENOENT is the
error code we get if the given path doesn't exist. This is easy to see
with 'fs whichcell':
$ fs whichcell notexist
fs: no such cell as 'notexist'
The VIOC_FILE_CELL_NAME pioctl also never returns ENOENT itself, so
this only happens if the given file doesn't exist. This behavior goes
back to OpenAFS 1.0.
To improve this, change GetCell() to report errors itself. So now
errors are reported from it consistently, and are printed for all
callers. For example:
$ fs whichcell notexist
fs: Failed to get cell for 'notexist'
fs: File 'notexist' doesn't exist
The message is a little redundant, but this lets us use the existing
error reporting from Die() while still providing context for what is
failing, since it may not be obvious for 'fs cleanacl' or 'fs getfid'.
Change-Id: Ib4a84288a9c2d94b2b0d3c4c360fc5c014e98b30
Reviewed-on: https://gerrit.openafs.org/15586
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Currently, 'fs getfid' fails if we cannot get the cell for the given
file via GetCell(). This GetCell call was added in commit d390df097c (fs
getfid output changed for consistency with Windows implementation) to be
more similar to the WINNT 'fs getfid', but the WINNT 'fs getfid' still
prints the fid if getting the cell fails (and has since it was
introduced in commit 5520747790 (windows-fs-getfid-20090511)).
GetCell() shouldn't normally fail if getting the fid succeeded, but in
case it does, don't prevent us from printing the fid. Change 'fs
getfid' to just say the cell is "unknown-cell" and keep going.
Change-Id: Idd4727304061e1ec4eeddd98bd9eaab5de96e2b6
Reviewed-on: https://gerrit.openafs.org/15585
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
After we get the fid for the requested path, 'fs getfid' then gets the
cell for the path:
GetCell(ti->data, cell);
But ti->data is the full path requested, whether -literal was given or
not. If the given path ends with a broken symlink/mountpoint or
nonexistent fid, we've already gotten the fid (if -literal was given)
but we'll still exit with an (often confusing) error:
$ fs getfid symlink.broken -literal
fs: no such cell as 'symlink.broken'
In addition, if we use 'fs getfid -literal' to get the fid of a
cross-cell mountpoint object, we'll get the wrong cell. We'll report
the cell of the mountpoint's target, instead of the cell of the
reported fid:
$ fs getfid /afs/example.com -literal
File /afs/example.com (1.16777244.1) located in cell example.com
To fix these, pass 'parent_dir' to GetCell() when -literal is given.
To do this, we need to not free parent_dir until later, so reorganize
the 'parent_dir' and 'last_component' vars to be freed at the end of
the loop, and change the 'continue' code paths to goto the end of the
loop instead.
With this, the cell is now reported properly for these cases:
$ fs getfid symlink.broken -literal
File symlink.broken (536871063.22.865) located in cell example.com
$ fs getfid /afs/example.com -literal
File /afs/example.com (1.16777244.1) located in cell dynroot
Change-Id: I8ec297dae84f677d530b6f7c39786f18c2a9c50f
Reviewed-on: https://gerrit.openafs.org/15584
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <mbarbosa@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Commit 3961e416f6 'rx: Cleanup and build simple.example' fails to
build on Solaris 11.3 or older due to undefined socket and resolver API
symbols, including bind, getsockname, connect, recvfrom, etc:
LD /.../src/rx/simple.example/sample_client
Undefined first referenced
symbol in file
bind /.../lib/libafsrpc.a(rx_user.o)
getsockname /.../lib/libafsrpc.a(rx.o)
gethostbyname sample_client.o
[...]
ld: fatal: symbol referencing errors. No output written to sample_client
This is because on Solaris, these have historically been supplied via
-lsocket, -lresolv, and other libraries as defined in the OpenAFS
variable XLIBS.
Add XLIBS to our link rules in the simple.example Makefile to avoid
these errors.
On Solaris 11.4, XLIBS is not required to build because the APIs
formerly found via XLIBS are now largely provided in libc.so instead,
with libsocket.so and libresolv.so maintained for compatibility as
filters on libc.so.
Change-Id: Id3b5d1903aa41807cca7a97d48dac9ff272101b1
Reviewed-on: https://gerrit.openafs.org/15789
Tested-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Currently, volinfo/volscan offers an optional -volumeid parameter,
allowing users to specify the id of a single volume to generate output
for. If this option is omitted, volinfo/volscan processes every volume
in the specified partition, or all local partitions if no partition is
specified. Internally, when the -volumeid parameter is not provided, its
corresponding variable defaults to 0, which volinfo/volscan interprets
as an indication to process all volumes.
Unfortunately, if an invalid volume id is specified (e.g., a volume name
instead of a number), volinfo/volscan incorrectly treats it as 0 and
processes all volumes instead of validating the input and notifying the
user. This issue occurs because strtoul(), the function used to convert
the volume id string to a number, returns 0 when it fails to perform a
valid conversion, leading volinfo/volscan to misinterpret invalid volume
ids as 0.
This commit fixes this issue by adding validation for the -volumeid
option. It parses the result from strtoul() and returns an error if the
volume id is invalid. This ensures that users are properly informed when
an invalid id is provided, preventing unintended processing of all
volumes in the given partition.
Change-Id: I166211c8814c13f4a79273efa6408a447f0855a9
Reviewed-on: https://gerrit.openafs.org/15771
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
In ostype.m4 and sysname.m4, we detect amd64 FreeBSD by matching $host
against "x86_64-*-freebsd*". On FreeBSD, `uname -p` on these systems
prints "amd64", but the config.guess from the GNU config project (that
is, <https://savannah.gnu.org/projects/config/>) translates amd64 into
x86_64 for FreeBSD, and has for a very long time.
For whatever (historical) reasons, anything built from FreeBSD ports
uses a version of the config.guess script that has FreeBSD-specific
modifications (which lives in /usr/ports/Templates/config.guess). This
version does not translate amd64 into x86_64, and so our $host looks
like, for example:
$ sh /usr/ports/Templates/config.guess
amd64-unknown-freebsd12.3
If regen.sh is run on a FreeBSD host, we pull our config.guess from
libtool, which normally is built from FreeBSD ports, and so results in
a host triplet with "amd64" for amd64 hosts. And so the build breaks
early on, because we don't recognize that we're on FreeBSD.
To accommodate this, match our amd64 FreeBSD host triplets against
amd64 or x86_64, so we can build using a config.guess from FreeBSD or
GNU upstream.
Change-Id: I372c9c9150b6639fa0cda96052cf50eb2857a3bb
Reviewed-on: https://gerrit.openafs.org/15159
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Måns Nilsson <mansaxel@besserwisser.org>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
afs_xsetgroups was using old-style function definitions, and lacked a
proper prototype. Modernize the function definition, and make a proper
prototype for it.
Change-Id: Ib11a7fc15afabdf0a538da4c1665acae6041fda5
Reviewed-on: https://gerrit.openafs.org/12708
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
Here, &avc->multiPage is just a struct afs_q*, so comparing it
directly to 'range' results in a compiler warning. Cast it to a struct
multiPage_range* to avoid the warning.
Change-Id: If37e078deadb15c07a1c87c8b5c4785f823f7182
Reviewed-on: https://gerrit.openafs.org/12706
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
A couple of places call afs_putpage outside of osi_vnodeops.c (where
it's defined). So, add a prototype for it in osi_prototypes.h. Also
make the call sites actually follow the prototype, by giving the
correct arguments in the AFS_SUN511_ENV case.
Change-Id: I2c9e500ee0fe544df64b4d023091f4a1ad965485
Reviewed-on: https://gerrit.openafs.org/12704
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
afs_osi_vget was called in a few different places, but it lacked a
proper prototype. Add one in afs_prototypes.h.
Change-Id: I74310bcee88a48ee98b8c2ec22fdbfda8d4e0324
Reviewed-on: https://gerrit.openafs.org/12703
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Currently, ez_create() fails to release cmdpath when it returns early
due to a failure returned by bnode_InitBnode(). This commit resolves
this issue by ensuring that cmdpath is properly deallocated in such
failure scenarios, thereby preventing memory leaks.
Change-Id: I03b137f9f45eca41c538574d842e99445bf55b2c
Reviewed-on: https://gerrit.openafs.org/15718
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Commit c66971ce42 'man-pages: Generate man
pages with Pod::Man' inadvertently broke the top-level Makefile.in
'pristine:' rule.
This leads to the following error with 'make pristine':
...
doc/man-pages/man5 \
doc/man-pages/man8 \
for i in doc/man-pages/pod*/*.pod.in; do \
/bin/rm -f ${i%.in}; \
done
sh: syntax error at line 15: `do' unexpected
*** Error code 3
make: Fatal error: Command failed for target `pristine'
Remove the stray line continuation so the pod file deletion script will
work properly.
Additionally, the doc/man-pages/man* file objects are directories;
therefore the existing pristine rule 'rm -f' command will fail to remove
them:
...
doc/xml/mobi-fixup.xsl \
doc/man-pages/man1 \
doc/man-pages/man3 \
doc/man-pages/man5 \
doc/man-pages/man8
rm: doc/man-pages/man1 is a directory
rm: doc/man-pages/man3 is a directory
rm: doc/man-pages/man5 is a directory
rm: doc/man-pages/man8 is a directory
*** Error code 2
make: Fatal error: Command failed for target `pristine'
Reinstate the former 'rm -rf' command so the man-pages/man* directories
will also be properly erased.
Change-Id: I11658de0c02679d6c4b57917949cf2a70c9c019f
Reviewed-on: https://gerrit.openafs.org/15782
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
The afs_orig_setgroups* function pointers are used for
storing/resetting the function pointers in sysent[].sy_callc. On at
least Solaris 11, these return an int64_t, so change the
afs_orig_setgroups* declarations to reflect that.
Change-Id: Ie86ee999084a8c08c564427e3308b1d592ef68f5
Reviewed-on: https://gerrit.openafs.org/12707
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
modlookup returns a uintptr_t, not an actual pointer. Cast the result
to a pointer to avoid a compiler warning.
Change-Id: I33cf4600d21a713be3f90c1b6d626bdab2c3da28
Reviewed-on: https://gerrit.openafs.org/12705
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Fix a few functions that were declared without a return type, or were
using old-style declarations.
Change-Id: I1d19d06a588ba2d2e5005bfe8ca5dd267018ccdd
Reviewed-on: https://gerrit.openafs.org/12702
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
The gid_t arrays we get from crgetgroups are const, so declare our
local gid_t array const, as well, to avoid a compiler warning.
Change-Id: Id8a375bb17b5bbd28e81460b6cb68711802850c3
Reviewed-on: https://gerrit.openafs.org/12701
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Many of our function callbacks for vnode ops have incorrect function
signatures or return types for Solaris 11, since Solaris has added or
changed the arguments to these functions over time. None of these
updates significantly change the code in our implementation of these
functions, but update the signatures to avoid compiler warnings.
This commit restricts updates to Solaris 11. Some of these updates may
have happened earlier (e.g. in Solaris 10, or our signature was just
always wrong), but this commit allows for at least one platform with
reduced warnings.
Change-Id: I974071fe55c8a31279888f62443e8a234a14cd4c
Reviewed-on: https://gerrit.openafs.org/12700
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
caller_context_t is a type itself, not a struct name.
Change-Id: I0966f5be326cdad706324d8547a63518bbce6edc
Reviewed-on: https://gerrit.openafs.org/12699
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Include sys/vmsystm.h, so we get a prototype for map_addr().
Change-Id: Ia8d20d35993eab58fb3530b52366276edef70d5e
Reviewed-on: https://gerrit.openafs.org/12698
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Reviewed-by: Marcio Brito Barbosa <marciobritobarbosa@yahoo.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Currently, gafs_fid takes a 'struct fid **' argument, and gives it to
afs_fid(). But afs_fid() takes a 'struct fid *', and the Solaris
vop_fid callback also takes a 'struct fid *'. Just change the argument
to 'struct fid *' to get rid of compiler warnings for both of these
mismatches.
Change-Id: Ie937e4b24ef51265a5957666eda496661f3943ad
Reviewed-on: https://gerrit.openafs.org/12697
Reviewed-by: Andrew Deason <adeason@sinenomine.net>
Tested-by: Andrew Deason <adeason@sinenomine.net>
The generate-man script is currently a shell script which invokes the
pod2man command for each pod file to be converted into a man page. This
makes the pod conversion slow, since we load Perl and create a Pod::Man
parser for each pod file. In addition to being slow, generate-man
leaves behind a partially created man page when an error is
encountered during the pod2man execution.
To fix these issues, rewrite generate-man as a Perl script which uses
the Pod::Man module directly. The Pod::Man parser is created only once
and is reused to generate each man page. The Pod::Man module supports
this type of batch mode operation by clearing its internal state after
each man page is created.
We have some special processing to determine the man page names for the
pages in section 3, so create a sub class to handle the pod filename to
man page title determination, and add a helper function to support
processing more than one section with a single parser instance.
Be sure to cleanup any partially created man pages if an error is
encountered during the pod to man conversion. This will let us use this
script in the Makefiles in the future.
Change-Id: I8d3cce1edc62c490e93d05f72609dfde4b599a1b
Reviewed-on: https://gerrit.openafs.org/15774
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: Mark Vitale <mvitale@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Originally, OpenAFS documentation was maintained in a separate tree, so
the doc directory may not be present when doing a build. However, the
docs have been maintained in-tree for many decades, and even though we
still distribute the doc tree in a separate tar archive, package
builders are accustomed to unpacking the docs archive in order to
package the man pages.
Clean up and simplify the top level makefile by removing the checks for
the doc directory. Unconditionally generate the Makefiles from
Makefile.in files in the doc tree.
Starting with this change, unpacking the doc tarball will be required
(no longer just optional) when building from source distribution
tarballs.
Change-Id: Idfadb33d365777a561dc64e7d336a49eb74b8b48
Reviewed-on: https://gerrit.openafs.org/15772
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Since the original IBM code import, the Unix cache manager has contained a few
fragments of apparently vestigial code related to processing directories via
RXAFS_BulkStatus.
Remove the unused code.
No functional change is incurred by this commit.
Change-Id: I60998b304c333ec177c1d88e5bea2e5beacabec3
Reviewed-on: https://gerrit.openafs.org/15398
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Mark Vitale <mvitale@sinenomine.net>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Commands like 'fs flush' and 'fs flushvolume' require the caller to be
able to lookup the target file, but 'fs flushall' has no access checks
at all, and hasn't since it was introduced in commit 4197bbecd9
(libafs: fs flushall for unix cm). This allows unauthenticated users
to flush the cache of files/volumes they have no access to, and means
flushing the entire cache requires less access than flushing parts of
the cache, which doesn't make much sense.
Change the command to only be runnable by the local superuser root,
and document the restriction.
Change-Id: I906d6c02a16b49ae31ab8e644a8ffb85c4e3434d
Reviewed-on: https://gerrit.openafs.org/15393
Reviewed-by: Cheyenne Wills <cwills@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Currently, we inhibit various -Wdeprecated-declarations warnings via
"#pragma GCC diagnostic warning". Some older compilers (like gcc 4.1 on
RHEL5) don't understand the pragma, but still need the warning inhibited
in order to build with --enable-checking. So just inhibit this warning
via command-line CFLAGS instead of using #pragma directives.
One source file, tests/auth/superuser-t.c, was inhibiting the
-Wdeprecated-declaractions warning unnecessarily (it has not been needed
since commit 5815a04cf1 (tests: Move token faking code to its own
file)). Just remove the warning inhibition there, instead.
Change-Id: I52b1aeeac8699f9a4820626e9f1349f8cd380585
Reviewed-on: https://gerrit.openafs.org/15777
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Heimdal's hcrypto declares various DES functions as deprecated. We use
these functions in various files, and so we inhibit the
-Wdeprecated-declarations warning so we can build with
--enable-checking.
Heimdal declares these functions as deprecated using the HC_DEPRECATED
(or HC_DEPRECATED_CRYPTO) macro, which conditionally expands to
__attribute__((deprecated)) depending on the platform. If we define
HC_DEPRECATED ourselves to nothing before including the relevant header
file, those functions will effectively not be declared deprecated. Some
of our source files do this to avoid the -Wdeprecated-declarations
warning.
Some of our code does one of these to avoid the warning, and some does
both. We should pick one or the other, and be consistent about it. In
this commit, get rid of defining HC_DEPRECATED (and
HC_DEPRECATED_CRYPTO) ourselves, and just inhibit the relevant warning
the same way we do for all other warnings.
All instances of this are also currently missing from the "Inhibited
warnings" section in CODING. Add all instances to that list.
Change-Id: I4d7ece94be22457ceefbe52b6ec286e67423e8cb
Reviewed-on: https://gerrit.openafs.org/15776
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
Since commit 840cf3b628 (afs: Introduce afs_kill_pending()),
osi_misc.c has lacked a newline at the end of the file. This triggers a
warning on some old compilers, such as gcc 4.1 on RHEL5, which breaks
the build when using --enable-checking:
[...]/src/libafs/MODLOAD-2.6.18-419.el5-SP/osi_misc.c:205:2: error: no newline at end of file
Add a newline to get rid of the warning/error.
Change-Id: Id5a3a3f36c4f51b36426b2fe78ac5afb1f4fb6b3
Reviewed-on: https://gerrit.openafs.org/15775
Tested-by: BuildBot <buildbot@rampaginggeek.com>
Reviewed-by: Michael Meffie <mmeffie@sinenomine.net>
