Package Details: openafs 1.8.13.1-1

Git Clone URL: https://aur.archlinux.org/openafs.git (read-only, click to copy)
Package Base: openafs
Description: Open source implementation of the AFS distributed file system
Upstream URL: http://www.openafs.org
Licenses: IPL-1.0
Conflicts: openafs-features
Submitter: None
Maintainer: Bevan
Last Packager: Bevan
Votes: 61
Popularity: 0.000000
First Submitted: 2006-02-01 17:18 (UTC)
Last Updated: 2024-12-21 09:26 (UTC)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 32 Next › Last »

Bevan commented on 2021-10-06 07:29 (UTC) (edited on 2021-10-06 07:42 (UTC) by Bevan)

drslmr: Thanks for noticing us here. The same error has been reported on the openafs mailing list: https://lists.openafs.org/pipermail/openafs-info/2021-October/043153.html

So far, it could not be reproduced but with your report it becomes pretty clear that it is an issue with 5.14.8 / 5.14.9 specifically. I will forward your report to the mailing list as well so this issue can be sorted out quickly.

drslmr commented on 2021-10-06 05:58 (UTC)

I reported a kernel bug, that may have to do with afs: https://bugs.archlinux.org/task/72340

Bevan commented on 2021-03-25 09:44 (UTC)

@kgizdov:

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:

[Unit]
Description=OpenAFS Client Service
Wants=network-online.target
After=syslog.target network-online.target dkms.service
Before=remote-fs.target

[Service]
Type=forking
RemainAfterExit=true
EnvironmentFile=/etc/conf.d/openafs
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
KillMode=mixed

[Install]
WantedBy=multi-user.target remote-fs.target

kgizdov commented on 2021-03-23 09:42 (UTC)

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 (UTC)

@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 (UTC)

@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 (UTC)

@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 (UTC)

@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 (UTC) (edited on 2020-10-13 14:05 (UTC) by gay)

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 (UTC)

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