[OpenAFS] ubik_Call returns 363546 suddenly
Benjeman Meekhof
bmeekhof@umich.edu
Sat, 5 Mar 2016 16:00:52 -0500
Some background: for several years now we've been using a combination
of Amanda backup and 'amanda-afs' which is a piece of code once from
Cornell somewhat modified over time to compile against newer versions
of afs. Briefly, amanda-afs is a collection of utils to tie afs
volume dumps into amanda.
For reasons yet unknown the 'volset dump' utility used in the process
stopped working recently. We're using openafs 1.6.14-219 as packaged
by Scientific Linux (a RHEL derivative).
I tracked this down to the following snippet of code. In this code
ubik_Call returns a code of '363546', nentries is 0, and since we get
no volumes returned that's the end of any further action. volname is
a wildcard string like "home..*". I've tried pointing the command at
volume sets on any of our 3 file servers.
Can anyone on the list offer any further hints to tracking this down?
It appears that the beginning of this problem correlates to our
vlserver machines receiving a package update that moved from afs
1.6.10 to 1.6.14. We're not experiencing any other issues with AFS,
and until this point have not had any issue with this utility.
-----
//* Now make the call to the vlserver */
for (si=0; si != -1; si=nsi) {
nentries = 0;
bulkentries.nbulkentries_len = 0;
bulkentries.nbulkentries_val = 0;
nsi = -1;
tcode = ubik_Call(VL_ListAttributesN2, uclient, 0,
&attributes, volname, si,
&nentries, &bulkentries, &nsi);
if (tcode) fprintf(stderr, "Error: Could not expand module lists
for '%s'! Return code was '%d'\n",volname,tcode);
if (nentries == 0)
{
fprintf(stderr, "Error: nentries = 0!\n");
}
(full code of util is at https://www.aglt2.org/amanda/amanda-afs-0.0.4.tar.gz)
Output:
]# ./volset dump our.afs.fs.server vicepe home..* 0 test
Error: Could not expand module lists for 'home..*'! Return code was '363546'
Error: nentries = 0!
Total bytes written: 0 (0.00MB, ?MB/s)
Thanks,
Ben