[Mailed to debian-user as well as this relevant (bug in my test program).]
According to joost witteveen:
> Are you sure you didn't have a typo there? didn't you mean
> /var/clients/kant/var/spool/cron/atjobs/.SEQ
> instead of
> /var/spool/cron/.SEQ
>
> (there's at least a "atjobs" missing).
Ah! You're very right. Thank you!
No I meant "/var/spool/cron/atjobs/.SEQ".
Sorry about that. Now I have:
kant:/var/tmp> ./st
stat("/boot/no/a" successful.
lstat("/boot/no/a" successful.
stat("/var/spool/cron/atjobs/.SEQ" successful.
lstat("/var/spool/cron/atjobs/.SEQ" successful.
So that wasn't the problem. Back to the original one. There seems to be bug
in the at package.
You see I've this problem running at as an ordinary user on the client:
kant:/var/tmp> at 2:2
Cannot access /var/spool/cron/atjobs: Permission denied
Looking at the at code, I found the line where it says the above, and
whipped up a simple test case that showed the same problem: my st program.
Unfortunately, it had (at least) one bug. The one you've pointed out.
So now back to the original problem:
Can you please try running "at 2:2" as an ordinary user on a client
that nfs mounts it's /var directory (or at least it's /var/spool/cron/atjobs
directory)
Turning on logging for nfsd as before, I run this as an ordinary user on
the client:
kant:/var/tmp> at 2:2
Cannot access /var/spool/cron/atjobs: Permission denied
In the nfs log on the server, I see:
[...]
nfsd[3388] 09/28/97 17:42 new_fh = /var/clients/kant/var/spool/cron/atjobs
nfsd[3388] 09/28/97 17:42 result: 0
nfsd[3388] 09/28/97 17:42 lookup [1 97/9/28 17:42:20 kant 0.100+100,4,24,25,29]
fh:/var/clients/kant/var/spool/cron/atjobs n:.SEQ
nfsd[3388] 09/28/97 17:42 new_fh =
/var/clients/kant/var/spool/cron/atjobs/.SEQ
nfsd[3388] 09/28/97 17:42 result: 0
nfsd[3388] 09/28/97 17:42 getattr [1 97/9/28 17:42:20 kant 0.100+100,4,24,25,29]
/var/clients/kant/var/spool/cron/atjobs/.SEQ
nfsd[3388] 09/28/97 17:42 result: 0
nfsd[3388] 09/28/97 17:42 read [1 97/9/28 17:42:20 kant 0.100+100,4,24,25,29]
/var/clients/kant/var/spool/cron/atjobs/.SEQ: 4096 bytes at 0
nfsd[3388] 09/28/97 17:42 result: 0
nfsd[3388] 09/28/97 17:42 write [1 97/9/28 17:42:20 kant 0.100+100,4,24,25,29]
/var/clients/kant/var/spool/cron/atjobs/.SEQ: 6 bytes at 0
nfsd[3388] 09/28/97 17:42 result: 0
nfsd[3388] 09/28/97 17:42 lookup [1 97/9/28 17:42:20 kant 0.100+100,4,24,25,29]
fh:/var/clients/kant/var/spool/cron/atjobs n:a0001d00dea622
nfsd[3388] 09/28/97 17:42 result: 2
nfsd[3388] 09/28/97 17:42 lookup [1 97/9/28 17:42:20 kant
1000.100+100,4,24,25,29]
fh:/var/clients/kant/var/spool/cron/atjobs n:a0001d00dea622
nfsd[3388] 09/28/97 17:42 result: 13
nfsd[3388] 09/28/97 17:42 lookup [1 97/9/28 17:42:27 kant 0.0+0]
fh:/var/clients/kant/var n:log
As root on the client I see this ("ls -la /var/spool/cron/atjobs/"):
kant# ls -la /var/spool/cron/atjobs/
total 3
drwx------ 2 daemon daemon 1024 Sep 28 17:41 .
drwxr-xr-x 5 root root 1024 Feb 19 1997 ..
-rw------- 1 daemon daemon 6 Sep 28 17:42 .SEQ
So what is that a0001d00dea622 file that somehow makes at fail? Is it the
script file that at is creating?
Hmm. Running a script like this as root an the client, while I'm "at 2:2"-ing
several times doesn't reveil anything:
---- script start ---
#!/usr/bin/tcsh
while(1)
ls -la /var/spool/cron/atjobs/
end
---- script end ---
Neither does the equivalent script on the server.
Do you have any idea how to trace this?
> Oh, yes, I am sortof soure I started the nessecary daemons!
Of course! Just making sure, you know. It didn't make sense to me.
Thanks,
MartinS
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
