Russ Allbery wrote:
Chun Tian (binghe) <[EMAIL PROTECTED]> writes:
Package: openafs-client
Version: 1.4.2-3
Severity: normal
I want to configure openafs-client to support NFS/AFS translator, the
first things seems to start afsd with -rmtsys.
I'm not sure if the NFS/AFS translator works in the current release of
OpenAFS for Linux. It may, but I've never tried it. It was only recently
fixed.
When I modify my /etc/openafs/afs.conf like this:
OPTIONS="-rmtsys
I found that:
1. When start afs client using /etc/init.d/openafs-client start, two
'afsd' process appears (without -rmtsys, there's only one).
2. When stop afs client using /etc/init.d/openafs-client stop, a 'afsd'
process still exist, I have to kill it later.
Did you stop the client after adding that options line and before starting
it again?
yes, I stop the client after adding that options line and before
starting it again.
It's normal for multiple afsd processes to be running, but they should all
be shut down with openafs-client stop. However, nothing about the startup
scripts knows anything about the NFS translator, and I don't see any
reason why they would work differently when it's enabled. If there's a
bug, it's probably with the translator, although I don't know why that
would be.
I'm using many Debian servers on i386 and amd64 to deploy openafs
network, I only see ONE afsd process when openafs-client is running.
Without -rmtsys, my process table is like this:
root 11297 0.0 0.0 0 0 ? S 08:31 0:00
[afs_rxlistener]
root 11299 0.0 0.0 0 0 ? S 08:31 0:00
[afs_callback]
root 11301 0.0 0.0 0 0 ? S 08:31 0:00
[afs_rxevent]
root 11303 0.0 0.0 2016 560 ? Ss 08:31 0:00
/sbin/afsd -afsdb -dynroot -fakestat
root 11305 0.0 0.0 0 0 ? S 08:31 0:00 [afsd]
root 11307 0.0 0.0 0 0 ? S 08:31 0:00
[afs_checkserver]
root 11309 0.0 0.0 0 0 ? S 08:31 0:00
[afs_background]
root 11311 0.0 0.0 0 0 ? S 08:31 0:00
[afs_background]
root 11313 0.0 0.0 0 0 ? S 08:31 0:00
[afs_cachetrim]
Only one REAL process is started, I think the others are kernel threads,
If I set -daemons argument on afs.conf, the number of afs_background
kernel thread will change.
With -rmtsys, my processes table is like this:
root 11876 0.0 0.0 0 0 ? S 08:34 0:00
[afs_rxlistener]
root 11878 0.0 0.0 0 0 ? S 08:34 0:00
[afs_callback]
root 11880 0.0 0.0 0 0 ? S 08:34 0:00
[afs_rxevent]
root 11882 0.0 0.0 2016 568 ? Ss 08:34 0:00
/sbin/afsd -rmtsys -afsdb -dynroot -fakestat
root 11884 0.0 0.0 0 0 ? S 08:34 0:00 [afsd]
root 11886 0.0 0.0 0 0 ? S 08:34 0:00
[afs_checkserver]
root 11888 0.0 0.0 0 0 ? S 08:34 0:00
[afs_background]
root 11890 0.0 0.0 0 0 ? S 08:34 0:00
[afs_background]
root 11892 0.0 0.0 0 0 ? S 08:34 0:00
[afs_cachetrim]
root 11893 0.0 0.1 3028 1812 pts/12 S 08:34 0:00
/sbin/afsd -rmtsys -afsdb -dynroot -fakestat
Two REAL processes is started, but this is normal, because the 2132-2141
lines of afsd.c says:
if (afsd_rmtsys) {
if (afsd_verbose)
printf("%s: Forking 'rmtsys' daemon.\n", rn);
code = fork();
if (code == 0) {
/* Child */
rmtsysd();
exit(1);
}
}
I think that the reason why I have two afsd processes, the first fork
the other, sine the Appendix A of OpenAFS Administration Guide say:
For users working on a translator machine's NFS clients to issue AFS
commands, the
-rmtsys flag must be included on the afsd command which initializes
the translator
machine's Cache Manager. The flag starts an additional daemon (the
remote executor
daemon), which executes AFS-specific system calls on behalf of NFS
clients. For a
discussion of the implications of NFS users issuing AFS commands, see
Setting the
AFSSERVER and AFSCONF Environment Variables.
If you have i386 debian box, I think its quite easy to find this (two
afsd, and one didn't close). Acturally, I'm still not sure the AFS/NFS
trans can work, studying. But when I stop openafs-client, the process
which the first afsd forked still here:
root 11893 0.0 0.1 3028 1812 pts/12 S 08:34 0:00
/sbin/afsd -rmtsys -afsdb -dynroot -fakestat
Seems Debian initscript use afsd -shutdown to stop afs client, maybe
this part have a bug?
Thanks.
Chun Tian (binghe)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
