Package Details: openafs 1.8.8-2

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: custom:"IBM Public License Version 1.0"
Conflicts: openafs-features
Submitter: None
Maintainer: Bevan
Last Packager: Bevan
Votes: 61
Popularity: 0.000013
First Submitted: 2006-02-01 17:18
Last Updated: 2021-12-01 16:36

Latest Comments

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

bidulock commented on 2021-11-30 21:29

Need to add libxcrypt to depends.

kaspi commented on 2021-10-25 12:31

Hi Bevan, indeed, it is most likely this (unfortunate) outage. Thanks for pointing it out!

Bevan commented on 2021-10-25 11:26

Hi Jan. Could that be caused by this outage?

https://cern.service-now.com/service-portal?id=outage&n=OTG0066507

kaspi commented on 2021-10-25 11:10

Hi all,

after updating the system, I have troubles using AFS (details follow) and I wonder if anyone experiences the same or potentially would know how to fix it.

The SW versions which I use: kernel 5.14.14-arch1-1, openafs 1.8.8-1 and openafs-modules 1.8.8-2. The first problem occurs when running aklog:

Authenticating to cell cern.ch (server afsdb1.cern.ch).
Trying to authenticate to user's realm CERN.CH.
Getting tickets: afs/cern.ch@CERN.CH
Using Kerberos V5 ticket natively
About to resolve name jkaspar to id in cell cern.ch.
# here it hangs for a minute
Error -1
Setting tokens. jkaspar @ cern.ch

Then, trying to ls a directory on AFS, I get a time out:

> ll /afs/cern.ch
ls: cannot open directory '/afs/cern.ch': Connection timed out

Thanks in advance,

Jan.

drslmr commented on 2021-10-08 06:38

Yes, it works for me now with: linux 5.14.8.arch1-1 openafs-modules-dkms 1.8.8-2

Thank you very much.

Bevan commented on 2021-10-07 19:41

The potential RIP with kernel 5.14 should be fixed by openafs-modules-1.8.8-2 and openafs-modules-dkms-1.8.8-2. See https://gerrit.openafs.org/#/c/14826 for the ongoing review of the fix.

Bevan commented on 2021-10-06 07:29

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

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

@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

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.