Package Details: openafs 1.8.8-1

Git Clone URL: (read-only, click to copy)
Package Base: openafs
Description: Open source implementation of the AFS distributed file system
Upstream URL:
Licenses: custom:"IBM Public License Version 1.0"
Conflicts: openafs-features
Submitter: None
Maintainer: Bevan
Last Packager: Bevan
Votes: 61
Popularity: 0.000177
First Submitted: 2006-02-01 17:18
Last Updated: 2021-07-30 22:03

Latest Comments

1 2 3 4 5 6 ... Next › Last »

Bevan commented on 2021-03-25 09:44


For AFS blocking reboot/shutdown having some effective KillMode could indeed help. When restarting the service we need to be careful: As far as I know, the openafs module needs to be reloaded before afsd is started again. I guess if systemd kills afsd, ExecStop=/usr/bin/rmmod openafs won't be executed afterwards. Also I'm not entirely sure if one even can unload the module if afsd crashed / was killed. Or if afsd is even killable. So I think we need to test this.

I myself only have a little test cell available where it's hard to reproduce these hang-ups. Could you test a modified service file in your environment for a while and report back? It uses KillMode=mixed and adds a few checks on startup to make sure that we do not run into some undefined behavior on restarts.

You can just save the following file as /etc/systemd/system/openafs-client.service:

Description=OpenAFS Client Service dkms.service

ExecStartPre=/bin/bash -c "findmnt /afs >/dev/null; test $? -ne 0 || (echo /afs is still mounted -- not starting && exit 1)"
ExecStartPre=/bin/bash -c "pidof afsd >/dev/null; test $? -ne 0 || (echo AFS client appears to be still running -- not starting && exit 1)"
ExecStartPre=/bin/bash -c "/usr/bin/lsmod|grep openafs >/dev/null; test $? -ne 0 || (echo openafs module still loaded -- not starting && exit 1)"
ExecStartPre=/usr/bin/modprobe openafs
ExecStart=/usr/bin/afsd $AFSD_ARGS
ExecStartPost=/usr/bin/fs setcrypt on
ExecStop=/usr/bin/umount /afs
ExecStop=/usr/bin/afsd -shutdown
ExecStop=/usr/bin/rmmod openafs


kgizdov commented on 2021-03-23 09:42

is it possible to adjust the KillMode=none in the service file to KillMode=control-group or KillMode=mixed at least? I've had the issue of AFS blocking reboot/shutdown or not being able to restart the service, because systemd can't manage it properly.

gay commented on 2020-10-20 00:57

@Bevan: Thanks again for your help. Trying again a week later, the package compiled cleanly. Since the source has evidently not changed, the problem must have been something with my system last week. Perhaps something did not update correctly without me noticing.

Bevan commented on 2020-10-13 19:06

@gay: That's weird. I cannot reproduce this issue. Did you clean the build directory between the builds? Maybe there is a partial build still lying around from your earlier attempts?

gay commented on 2020-10-13 16:52

@Bevan: Thanks for the very quick reply and for pointing out that I am missing bison.

However, it seems that I receive the exact same error as reported below (even the addresses) with /usr/bin/yacc from bison 3.7.2-1 (the most recent version of bison), all of base-devel installed and all packages up to date.

It is, of course, possible that I am somehow missing something again.

A quick search reveals that similar errors have popped up periodically with openafs. (Apparently that was occasionally related to both byacc and bison being installed, but it's not that in my case.)

Bevan commented on 2020-10-13 14:21

@gay: the packages in the AUR assume that all packages from the base-devel group are installed: pacman -S base-devel

This also includes the bison package which contains yacc. byacc-bison in the AUR is an alternative implementation which seems to be missing some symbols required by openafs.

gay commented on 2020-10-13 14:04

I am having difficulty compiling this. Are there maybe missing dependencies? The make process complains about missing yacc. I tried installing byacc-bison from AUR that provides /usr/bin/yacc, but make is still not happy:

/usr/bin/ld: compile_et.o: in function `main':
compile_et.c:(.text+0x7f5): undefined reference to `yyin'
/usr/bin/ld: compile_et.c:(.text+0x813): undefined reference to `yyout'
/usr/bin/ld: compile_et.c:(.text+0x9d0): undefined reference to `yyout'
/usr/bin/ld: compile_et.c:(.text+0xc74): undefined reference to `yyin'
/usr/bin/ld: compile_et.o: in function `yyerror':
compile_et.c:(.text+0xf2e): undefined reference to `yylineno'
/usr/bin/ld: error_table.o: in function `yyparse':
error_table.c:(.text+0x9ab): undefined reference to `yylex'
/usr/bin/ld: error_table.c:(.text+0xefe): undefined reference to `yylex'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:39: compile_et] Error 1

nickoe commented on 2020-07-08 22:55

@Bevan, ok, thank you for looking into this and maintaining the package :)

Bevan commented on 2020-07-08 21:38

@nickoe: I had another look and I think there is not much we can do about that. The source code contains the __FILE__ macro in many places and the build system is written in a way that the source code location is given as absolute path to the compiler. It's mostly a cosmetic warning. A possible consequence is that certain error messages contain the path where the openafs package was built.

nickoe commented on 2020-07-07 11:52

@Bevan, ok no worries. I noticed this in a couple of packages by now. Maybe it is a new check that has been added to makepkg.